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4.  AktinMt 

This 'report  presents  descriptions  and  critiques  of  several  lov-level  bardvarc  fault 
inatruaentation  schesias  for  potential  application  in  a  digital  flight  con 
*rol  systea  (DFCS)  siaulator.  Representing  varying  degrees  of  sophistication,  these 
cheaes  are  tailored  to  enhance  test  validity  and  productivity.  Particular  atten- 
tlOT  is  therefore  directed  toward  the  capabUitlea  offered  by  the  varioue  .cheaes,  as 
well  as  their  proper  utilization.  Factors  such  as  fault  detection  coverage, 
latency  tlae,  and  recovery  froa  transients  are  stressed.  Also,  the  role  of  the  FIU  is 
ed  in  detail.  This  tends  to  eaphasize  low-level  fault  injection,  such  as  that  on 
chip  pin  level.  Such  testing  should  prove  valuable  despite  the  trend  toward  VISI 
|>^e?7  Large-Scale  Integration)  circuits  because  correlation  of  present  chip-versus-card 
(fault  observability  may  be  useful  in  test  case  definition  for  VLSI  iaolcaencaclonit. 
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FOSCWORO 


This  report  presents  descriptions  end  critiques  of  severel  low-ievel 
herdware  fault  insertion  and  Instruaentatlon  systeai  (FIIS)  schemes  for 
potential  application  in  a  digital  flight  control  syst«B  (DFCS)  simulator. 
Representing  varying  degrees  of  sophistication,  these  schemes  are  tailored 
to  enhance  test  validity  and  productivity,  especially  in  assessing  I^CS 
fault  detection  mechanisms  with  regard  to  coverage  and  latency  times. 
Particular  attention  Is  therefore  directed  toward  the  capabilities  offered 
by  the  various  schemes,  as  well  as  their  coordinated  utl 11  ration  to  enable 
overall  coverage  measures. 

Prepared  under  Rational  Aeronautics  and  Space  Administration  (RASA) 
Ck)ntract  NAS2-115n,  this  study  has  been  funded,  directed,  and  technically 
supported  by  the  Federal  Aviation  Wmlnlstrat' on  (FAA),  Additionally,  the 
ultimate  objectives  of  this  study  have  been  significantly  fostered  by 
recent  simulator  test  facility  anhaneenents  by  the  NASA>Ames  Research 
Center  (ARC).  The  Intant  of  all  study  participants  has  been  to  address 
certain  vital  certification  technology  Issues  In  a  responsive  and 
definitive  manner. 

This  report  has  also  been  published  as  Lockheed-Ceorgla  Company 
Engineering  Report  Ko.  (.G83ER0087, 


m 


TABLE  or  COrmiTS 


Sfctlon  Tltl»  Paf 

FOREWORD  111 

LIST  OF  FIGURES  vil 

LIST  OF  TABLES  vlii 

1 . 0  SUMMARY  ’ 

1.1  E*«cutlv«  Summary  2 

1.2  Ganar al  Problam  2 

1.3  Spaciflc  Problems  ^ 

1.4  Racoomandations  5 

2.0  BACKGROURD  T 

2. 1  Abbravlatlona  7 

2.2  Terminology  9 

2.3  FAA  Regulatory  Needs  10 

2.4  Assuranoa  Technology  Needs  ii 

2.. 5  Testing  Technology  Issues  11 

2.6  Predecessor  R&T  Activities  12 

2.7  RDFCS  Facility  Concerns/Features  12 

2.8  Potential  FIIS  Benefits  13 

3.0  OBJECTIVES  AMD  SCOPE  15 

3.1  Ultimate  Goals  ^  16 

3.2  Prassatic  Objectives  i6 

3.3  Study  Objectives  17 

3.4  Study  Orientation  17 

3.5  Scope  of  the  Study  18 


V 


TABLE  or  COETPrrs  Cont'd 


Seotlon 

•  u.o 


Tltl« 


TASK  RESULTS 

4. 1  ProblOB  Analysis  and  Potential  Solutions 

4.1.1  FITS  Motivation  and  Requlrenents 

4.1.j  ROfCS  Facility  Assessment 

4.1.3  Potential  Testing  Schemes 

4.1.4  Fault  and  Failure  Detection  in 
the  RDFCS 

4.2  Candidate  FIIS  Architectures 

4.2.1  Option  One:  Software  Modified 
System 

4.2.2  Option  Two:  Modest  System 
Modifications 

4.2.3  Option  Three:  Extensive  System 
Modifications 

4.2.4  Option  Four:  Full-Scope  System 
Modifications 

4.3  Summary  and  Critique  of  Recommendations 


REFERENCES 


LI5T  or  PICUMa 


Pigur* 

Tltl« 

Page 

1 

Hultl>Stag«  FIIS  Oev«lo{ai«nt  and  Utilization 

18 

2 

Data  Flow  in  a  Rapreaantativa  FCC  Channal 

21 

3 

Input  Data  Handling  in  a  Rapraaantativa  FCC  Channal 

22 

4 

Basic  Functional  Content  of  a  FCC  Processor 

23 

5 

FCC  Control  Store  Fields 

31 

6 

BDFCS  Facility  Layout 

33 

7 

Idealized  Failure  Effects  Testing  Scenario 

40 

8 

FIIS  Option  1  Architecture 

46 

9 

PDP-11/60  FIIS  Software  Structure 

47 

10 

FIIS  Option  2  Architecture 

52 

11 

Bus  Hoaitor/ Recorder  Block  Diagraa 

53 

12 

FIIS  Option  3  Architecture 

54 

13 

PDP-11/24  FIIS  Software  Structure 

56 

14 

FIIS  Option  4  Architecture 

59 

15 

Parallel  Chip  Unit 

60 

1 

i 


vll 


LIST  OF  TABLfcS 


Tablt  Title  Page 

1  FIIS  Technology  Orientation  2 

2  FIIS  Study  Conclusions  3 

3  FIIS  Mechanization  RecoBusendatlons  5 

4  Microprocessor  Faults  27 

5  Shift-Rotate  Register  Faults  29 

6  Interrupt  Controller  Faults  30 

7  Control  Store  Faults  30 

8  New  Software  Modules  for  Option  1  47 

» 

9  FIU  Comfflands  49 

10  Software  Modules  for  Options  3  and  4  51 

11  FIIS  Option  Allocation  Matrix  62 

12  Cost/Benefits  Projections  62 

13  Sumnary  of  Relevant  FIIS  Features  ^  63 

vfll 


1.0  SUMHARY 


Regulatory  needs  of  the  FAA  have  been  assessed  with  regard  to  fault 
survivability  of  critical  digital  systems,  and  remedial  facilities  and 
investigations  have  been  defined.  The  assessment  'is  largely  based  on 
requirements  deriving  from  FAA  Advisory  Circular  No.  (AC)  25.1309-1  (Ref. 
1),  and  the  investigations  are  based  on  current  or  projected  capabilities 
in  the  RDFCS  (Reconfigurable  Digital  Flight  Control  Systems)  Facility  at 
NASA-ARC,  especially  those  of  recently  installed  fault  injection  unit 
(FIU). 

This  study  surveys  the  various  types  of  fault  detection  mechanisms 
used  in  DFCSs  to  determine  the  occurrence  of  a  hardware  fault,  and  detailed 
consideration  is  given  to  various  test  schemes  to  evaluate  their  accept¬ 
ability.  Factors  such  as  fault  detection  coverage,  latency  time,  and 
recovery  from  transients  are  stressed.  Also,  the  role  of  the  FIU  is 
examined  in  detail.  This  tends  to  emphasize  low-level  fault  injection, 
such  as  that  on  a  chip-pin  level.  Such  testing  should  prove  valuable 
despite  the  trend  toward  VLSI  (very  large-scale  integrated)  circuits 
because  correlation  of  present  chlp-versus-card  fault  observability  may  be 
useful  in  test  case  definition  for  VLSI  implementations. 

In  any  circumstance,  as  more  definitive  and  conclusive  test  results 
are  sought,  greater  consideration  must  be  accorded  to  instrumentation  to 
observe  the  sequences  of  elemental  events  issuing  from  the  injected 
faults(s).  Such  instrunentation  ideally  should  encompass  hardware  and 
software,  multiple  computer  channels,  and  overall  time  correlation. 
Adequate  capacity  must  also  exist  to  assimilate,  interpret,  and’  store  the 
associated  test  data  to  properly  realize  the  benefits  of  automated  testing. 

Although,  the  recently  installed  FIU  adds  substantially  to  the  RDFCS 
facility,  the  overall  low-level  test  capability  is  adjudged  to  lack  suit¬ 
able  instrumentation.  Several  approaches  to  correcting  this  deficiency  are 
therefore  offered,  but  all  priorities  considered,  the  most  prudent  course 
now  is  to  systematically  develop  and  apply  the  basic  capability  enabled  by 
the  FIU.  This  is  supported  and  amplified  by  the  Investigation  plan  herein. 
Three  additional  levels  of  facility  upgrading,  including  full  FIIS 
capability,  are  also  defined,  along  with  a  description  of  the  additional 
classes  of  investigations  thereby  enabled. 
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1 . 1  EXECUTIVE  SUMHAHY 


Although  the  recently  added  low-level  fault  injection  capability  In 
the  HDFCS  laboratory  at  MASA-ARC  is  both  extensive  and  usable,  certain 
instrumentaion  enhancements  are  needed  to.  complement  the  FIU  and  enable 
precise  investigation  of  the  fault  tolerance  mechanisms.  Also,  certain 
software  additions  or  modifications  to  the  existing  RDFCS  facility  can 
substantially  improve  the  productivity  and  quality  of  investigations.  This 
study,  which  constitutes  the  first  attempt  to  address  such  needs,  has 
resulted  in  the  definition  of  four  levels  of  FIIS  capability  based  on  the 
composition  and  constraints  of  the  existing  RDFCS  facility.  The  four  FIIS 
configurations  are  summarized  in  Section  1.4,  and  Tables  1  and  2  provide 
some  associated  background. 


TABLE  ] .  FIIS  TECHNOLOGY  ORIENTATION 


AS«CT 

OVEHAU 

ASSUHANCE 

TESTING  IN 

GENERAL 

TESTING  OF  FLIGHf 
COMltOl  COMrUTERS 

HIGH  ASSUHAT-ICI 
LEVEU  fO« 

CMTICAL  OFCS. 

INTRACTAEIUTY  OF 
THOROUGH  TESTIFC 

IMPACT  OF  elemental 
COMPUTER  HARDWARE 
FAULTS 

COMTUCATION 

FAULT  TOIKANCE 
COMfOUNOING  OF 
ASSmiANCE  TASKS 

large  NUMtER  Of 

FAULT  CASES  TO  RE 
IDENTIFIED  AND  AFFIIED 

SENSITIVITY  TO 

TEST  ENVIRONMENT 

TECHNOLOGY  BJL* 

COMFLEMtNTAXITY 

Of  ASSUHANCE 
METHODS 

TEST  CASE  DESIGN 

AND  INTERfRETATIOM 

VALID,  OBSERVAilE, 

AND  EFFICIENT  LOW- 
LEVEL  TESTING 

FIR  EMFHASIS 

REAL-TIME  TEST 
CONFIRMATION  OF 
FAULT  TOURANCE 

DEFENDADLE  AND 
PRODUCTIVE 

TESTING 

EXPLOITATION  OF 
EXISTING  facilities 
(•.g.,  FIU) 

1 .2  GENERAL  PROBLEM 


The  general  problem  addressed  in  this  study  is  that  of  defining  FIIS 
configurations  that  to  some  useful  extent  meet  the  following  requirements 
within  the  context  of  the  RDFCS  facility  and  the  existing  FIU; 


o  Non-interference  with  real-time  RDFCS  operation 
o  Arbitrary  automated  control  of  fault  Insertion/removal 
o  Low-level  hardware  and  software  instrumentation 
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TABLE  2.  FlIS  STUDY  CONCLUSIONS 


OVERALL 

ASSURANCE 

TESTING  IN 

GENERAL 

testing  of 

flight  control  computers 

ntORlEM 

IMPROVED  ASSURANCE 

METHODS  AND  PRAOICES 

MANDATORY  TO  CONFIRM 

HIGH  ASSURANCE  LEVELS 
• 

TEST  FROOUCtIVITY  VITAL  TO 
AfPLCAHON  OF  THOROUGH 
SET  OF  TEST  CASES 

PRESENT  FlU  LACKS  PESCIUTICN  IN 
RDFCS  INSTAILAIICN  FOR  NEEDtD 
IF'VESTIGAriCNS 

COMPLICATION 

INCREASED  EFFORT  AND 
RESOURCES  NECESSARY 

TO  COPE  WIIH  INCREASED 
COMPLEXITY  &  FAULT  CASES 

ARBITRARY  CONTROL  OF  FAULT 
REMOVAL,  HEALING,  AND 
INSERTION  NOT  CURRENTLY 
AVAILABLE 

REAL-TIME  SIMULATOR  ROLE  C* 
ACCEPTABILITY  OF  LOW-LEVEL 
TESTING  NOT  YET  tSTABLISHtO 

TECHNOLOGY  ISSliE 

CONClUSIL'CNtSS  OF  LOW- 
LEVEL  lESilNG  USING  PRECISE 
MODELS  AS  execution 
MONITORS 

DEFINITION  AND  IMPLEMEN¬ 
TATION  OF  COMPREHENSIVE 

testing 

RECOAVAENDED  TEST  SPECIL.ENS 
AND  INSTRUMENTATION 

F.NABLE  ADVANCED  METHODS 

AND  CAPABILITIES 

Fits  EMPHASIS 

HIGH  FIOFLITY  FAILURE  EFFECTS 
RESULTS  TESTING  USING  REAL¬ 
TIME  SIMULATOR  ENVIRON¬ 
MENT 

RECOMMENDED  FIIS  ARCHITEC¬ 
TURES  emphasize  automated 
NON-INTERFERENCE  TESTING 

CPIlMIZAriCN  OF  FIIS  architec¬ 
tures  based  on  existing  facility 
constraints 

o  Multiple  RDFCS  channel  observations 

o  Correlated  data  retrleval/storage 

o  Efficient  test  loop  operation. 

Since  the  extent  to  vihleh  these  requirements  are  satisfied  is  dependent 
upon  resources  expended,  it  is  appropriate  to  delineate  several  increments 
of  cost/capability.  Accordingly,  four  separate  configurations  have  been 
defined: 


o  Existing  system  vrlth  only  softwai  e  modifications 

o  Improved  system  based  on  modest  hardware  modifications  and 
appropriate  software  changes 

0  Advanced  system  based  on  extensive  modifications 

0  Superior  system  based  on  the  ful.  scope  of  feasible  modifica¬ 
tions. 

To  motivate  and  substantiate  these  FIIS  configurations,  associated 
simulator  investigation  plana  have  also  been  formulated.  These  plans  serve 
to  Indicate  how  FIIS  capability  can  aid  certification  technology  and  to 
identify  cost s/bfnef its  tradeoffs  in  upgrading  the  present  RDFCS  facility. 
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1.3  SPECIFIC  PROBLEHS 


From  the  outset  certain  soecific  problems  have  been  recognized  as 
highly  important  to  the  outcome  of  the  study.  These  concerns  are  based  on 
familiarity  with  testing  of  digital  flight  systems  in  general  and  the 
operation  of  thv^  RDFCS  facility  in  particular.  Included  among  these 
concerns  are  the  follovrtng: 


o  Autopilot  Disconnect  -  a  large  number  of  computer  hardware  fault 
insertions  result  in  autopilot  disconnect,  which  owing  to  the 
need  for  manual  reset,  inhibits  automated  testing 

o  Flight  Computer  Memory  Volatility  -  a  significant  number  of 
computer  hardware  fault  insertions  result  in  eradication  of  the 
flight  program  in  the  core  memory,  thereby  necessitating 
reloading  prior  to  the  continuation  of  testing 

o  Fault  Introduction  Phasing  -  there  exists  no  way  to  precisely 
control  the  introduction  of  faults  relative  to  the  flight 
software  execution  runstreain 

o  Analog  Data  Digitization  -  some  of  the  essential  test  data  are 

not  available  in  digitized  form  for  the  PDP-11/60  computer 

o  Massive  Test  Results  Data  -  efficient  and  highly  observable 

testing  generates  real-time  test  results  pr '•cessing  demands  to 
alleviate  storage-related  problems 

o  PDP-11/04  Limitations  -  because  of  its  slowness  and  lack  of 

flexibility,  the  PDP-11/04  impedes  the  full  realization  of  FIIS 
capability 

o  Multiple  Channel  Monitoring  -  the  PDP-11 /04  can  only  access  one 
flight  computer  channel  at  a  time,  an  impediment  to  precise 
testing  that  may  be  aggravated  by  channel  skewing  and  transport 
lags 

o  Time  Correlation  -  there  exists  no  universal  time  base  to 

correlate  events  in  different  channels  or  various  parts  of  the 
test  loops 

0  Instrumentation  Limitations  -  many  of  the  foregoing  points  are 

among  the  causes  of  a  fundamentally  inadequate  instrumentation 
capability  to  support  certain  basic  types  of  low-level 
investigations . 

It  should  be  noted  that  all  ot  these  problems  result  from  trying  to 
use  a  system  simulator  for  high-resolution,  low-level  testing,  or  something 
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other  than  i^iat  it  was  actually  optiaized  for.  '••'hile  there  is  clearly 
merit  in  the  high  fidelity  ex*alnatlon  of  low-level  faults  as  is  pcssitle 
during  real-time  system  operation,  the  full  Implications  of  thiis  were  not 
at  issue  during  the  HOFCS  development  contract.  Beginni.ng  witn  the 
definition  of  the  associated  requirements,  this  st’udy  has  uncertaner  tc 
resolve  the  attendant  problems  and  to  maxiaize  FI 15  capaoility. 

1 . 4  RECOMMEMDATIOMS 


A  family  of  four  FIIS  architectures  is  summarized  in  Table  :  along 
with  sev'ral  miscellaneous  recommendations  for  facility  laprovement .  Th.e 
four  architectures  are  differentiated  by  the  expense  involved  in  tneir 
Implementation  and  by  the  failure  effects  investigation  capabilities 
thereby  provided.  To  enable  an  inltltal  phase  of  such  investigations,  the 
first  FIIS  architecture  is  recommended  for  appreciably  extended  capability 
at  modest  cost.  The  associated  implementation  experience  seouid  also  permit 
lowered  risk  realization  of  the  other  options.  Rather  conveniently, 
the  miscellaneous  recommendations  might  be  added  as  desired  during  any 
phase . 


TABLE  3.  FUS  MECHANIZATION  RECOMMENDATIONS 
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Basically,  the  benefits  of  the  various  options  range  frotn  Increased 
test  productivity  for  the  Initial  modifications  to  extended  test  signif¬ 
icance  and  resolution  for  the  full-scope  modifications.  Both  aspects  are 
highly  Important,  but  the  most  crucial  assurance  technology  issues  focus  on 
the  need  for  responsive  high-resolutlon  testing  to  Investigate  transient 
phenomena.  As  a  consequence.  It  Is  appropriate  to  proceed  with  a  multi¬ 
phase  implementation  of  the  Table  3  recommendations,  or  refinements 
thereof.  Mote  that  these  modifications  to  the  existing  facility  are 
deceptively  difficult  to  accomplish  without  close  familiarity  with  the 
overall  RDFCS  simulator  Implementation  details. 
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2.0  BACKGROUND 


far  as  digital  flight  systan  failure  modes  and  effects  are 
concerned,  the  apprehensions  expressed  at  the  Government/Industry  Workshop 
on  Methods  for  Certification  of  Digital  Flight  Controls  and  Avionics  in 
1976  (Ref.  2)  have  proven  to  be  largely  warranted.  This  is  not  a  general 
indictment  of  digital  implementation,  but  recognition  of  the  tendencies 
inherent  in  the  increased  complexity  of  digital  over  analog  mechanization. 
This  complexity,  which  becomes  quite  evident  in  fault  case  definition, 
tends  to  mask  design  and  implementation  discrepancies. 

Much  of  this  complexity  relates  to  software,  but  in  this  study  only 
hardware  faults,  and  not  software  discrepancies,  are  of  direct  concern. 
Since  software  procedures  are  often  used  to  detect  or  isolate  hardware 
faults,  attention  is  ultimately  focused  on  the  adequacy  of  such  software. 
The  dellneatlor.  between  hardware  and  software,  moreover,  is  sometimes 
barely  distinguishable,  and  this  Is  a  particularly  significant  aspect  of 
digital  flight  systems.  This  phenomenon  is  addressed  and  reflected  by  test 
validity  requirements  that  encourage  low-level  fault  insertion  in  a 
high-fidelity  environment,  or  in  the  case  at  hand,  a  real-time  system 
simulator. 

« 

2.1  ABBREVIATIONS 


AC  Advisory  Circular 

ADC  Analog-to-Dlgltal  Converter 

AFCS  Automatic  Flight  Control  System 

AIRLAB  Avionics  Integration  Research  Laboratory  (at  NASA  LaRC) 
ARC  Ames  Research  Center  (NASA) 

AWI  AFCS  Warning  Indicator 

BIT  Built-in  Test 

BMRU  Bus  Monitor/ Recorder  Unit 

CAPS  Collins  Adaptive  Processor  System 
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CPU 

CTA 

DAC 

D/D 

DEC 

DFCS 

DMA 

FAA 

FCC 

FD 

FI 

FIFO 

FITS 

FIU 

FTMP 

HZ 

IRAD 

IC 

I/O 

K 

URC 

LSR 

MDICU 

msec 

NASA 

NPR 


Central  Processor  Unit 
CAPS  Test  Adaptor 
Digltal-to-Analog  Converter 
Dig! ta 1- to-Di sc  r etc 
Digital  Equipment  Corporation 
Digital  Flight  Control  System 
Direct  Memory  Access 
Federal  Aviation  Administration 
Flight  Control  Computer 
Flight  Director 
Fault  Injector 
Fi rst-in/First-out 

Fault  Insertion  and  Instrumentation  System 

Fault  Injection  Unit 

Fault-Tolerant  Multiprocessor  (Draper) 

Hertz 

Independent  Research  and  Development 

Integrated  Circuit 

Input/Output 

Thousand 

Langley  Research  Center  (NASA) 

Logic  State  Recorder 

Modular  Digital  Interface  Control  Unit 

Millisecond 

National  Aeronautics  and  Space  Administration 
Non-Processor  Request 
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PROM 

Programmable  Read-Only  Memory 

RAM 

Random  Access  Memory 

RDFGS 

Reconfigurable  DFCS  (at  NASA-Ames) 

ROM 

Read-Only  Memory 

SAS 

Stability  Augmentation  System 

VLSI 

Very  Large-Scale  Integrated 

^sec 

Microsecond 

2,2  TERMINOLOGY 


By  defining  and  elaborating  on  the  use  of  key  terras  at  the  outset,  it 
is  hoped  that  the  ensuing  issues,  concepts,  and  recoooendations  will  be 
rendered  nore  accessible  and  meaningful.  In  addition  to  the  following, 
other  terms  defined  in  AC  Mo.  25.1309-1  (Ref.  1)  and  the  FAA  Validation 
Handbook  (Ref.  3)  are  quite  important. 

A  CRITICAL  FUNCTION  is  one  whose  availability  is  necessary  to  ensure 
the  safe  flight  and  landing  of  an  aircraft.  Therefore,  failure  conditions 
that  can  result  In  the  loss  or  appreciable  degradation  of  a  critical 
function  must  be  extremely  Improbable,  or  of  an  incidence  rate  of  1.0  x 
10  '  per  hour  of  flight  or  less. 

An  ESSENTIAL  FUNCTION  is  one  whose  availability  is  necessary  to  ensure 
the  basic  safety  and  flyabllity  of  an  aircraft  under  all  operating  condi¬ 
tions,  even  the  most  adverse.  Therefore,  failure  conditions  that  can 

result  in  the  loss  or  significant  degradation  of  an  essential  function  must 

-5 

be  Improbable,  or  of  an  Incidence  rate  of  1.0  x  10  per  hour  of  flight  or 
less. 

A  HARDWARE  FAULT  is  the  anomalous  behavior  resulting  from  an  elemental 
physical  event,  which  may  be  due  to  a  transient  malfunction  or  a  permanent 
impairment  of  hardware.  Depending  on  the  Implementation,  certain  faults 
cannot  affect  the  performance  of  the  system  function(s),  and  these  are 
referred  to  as  "don't  cares."  Obviously,  only  those  faults  that  can  affect 
system  functions  are  of  consequence.  Such  faults  are  said  to  be 
distinguishable. 
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FAULT  DETECTION  is  the  recognition  and  declaration  of  an«naiou3 
behavior  by  one  or  more  system  mechanisms  vflth  discretionary  capability. 
Beyond  mere  detection  of  faults,  it  is  necessary  to  isolate  or  compensate 
for  them  to  maintain  adequate  performance  of  the  system  function(3). 

FAULT  LATENCY  TIME  is  the  duration  from  the  occurance  of  a 
debilitating  elemental  event  until  the  resultant  anomalous  behavior  is 
detected.  This  delay  may  result  from  the  fact  that  the  effects  are  not 
immediately  distinguishable,  at  least  within  the  capabilities  of  the  fault 
detection  mechanisms. 

FAULT  DETECTION  COVERAGE  is  the  composite  likelihood  of  recognizing 
all  distinguishable  faults,  weighted  according  to  their  respective  failure 
rates,  by  one  or  more  of  the  fault  detection  mechanisms.  In  a  represen¬ 
tative  computer,  the  identification  of  the  entire  set  of  distinguishable 
f.jults  and  their  respective  failure  rates  is  clearly  a  major  challenge. 

2.3  FU  REGULATORY  NEEDS 


Certification  of  critical-  or  essential  systems  requires  an  intehsive 
assessment  of  safety-related  implementation  aspects.  In  the  case  of 
digital  mechanization,  the  newness  of  the  associated  technology  along  with 
Inherent  system  complexity  tends  to  complicate  the  assessment  process.  One 
way  to  inhibit  this  tendency  is  through  the  availability  and  use  of 
practical,  dependable  means  to  conduct  the  assessment. 

Accordingly,  the  intent  of  this  study  has  been  to  review  and  propose 
means  to  aid  FAA  and  industry  engineers  in  demonstrating  the  acceptability 
of  hardware  fault  tolerance  mechanisms.  Demonstration  of  properties  such 
as  CPU  (central  processor  unit)  self-test  coverage  or  comparator-monitor 
coverage  are  therefore  the  ultimate  end  of  this  study,  and  associated 
testing  techniques  the  partial  means.  To  support  regulatory  needs,  some 
emphasis  is  also  placed  on  resolution  offered  by  various  test  levels  or 
methods  and  on  the  essential  complementarity  of  different  types  of 
assurance  methods  (see  Ref.  4). 
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2.4  ASSURANCE  TECHNOLOGY  NEEDS 


As  described  in  Ref.  5,  system  validation  is  acccwiplished  by  the 
mutually  reinforcing  contributions  of  the  three  classical  approaches  to 
assurance:  analysis,  testing,  and  inspection.  Sasically,  global 

confirmation  of  system  acceptability  is  based  upon  analysis,  which  in  turn 
is  selectively  supported  by  testing.  Scrutiny  of  these  activities  Is  the 
vital  role  of  inspection.  Application  of  this  approach  is  described  in 
Ref.  4. 

The  close  coupling  of  analysis  and  testing  is  crucial  for  high 
assurance  levels  associated  with  critical  or  essential  system  functions. 
This  coupling  is  fostered  by  this  definition  study  in  that  simulator  test 
investigations  have  been  planned  to: 

o  Generate  empirical  data  for  analysis  methods 

-  such  as  transient  or  fault  latency  data  for  reliability  and 
analysis  models 

o  Calibrate  or  confirm  fault  detection  coverage  for  analysis 
>  such  as  needed  to  comply  with  AC  No.  25.1309-1. 

o  Investigate  analytically  Intractable  issues 

-  such  as  applications  software  detection  of  CPU  faults,  which 
is  not  feasible  using  many  emulators. 

All  of  these  represent  vital  assurance  technology  needs  that  transcend 
testing  per  se. 

2.5  TESTING  TECHNOLOGY  ISSUES 


Basically,  the  hardware  failure  effects  testing  issues  are  summarized 
as  follows: 

o  Low-level  fault  insertion  mechanisms 

o  Arbitrary  control  of  fault  insertion/removal 

o  Non-consequentlal  Interference  with  "normal"  real-time  operation,, 
faulted  or  non-faulted 
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o  Minimized  manual  intervention  in  the  testing  process 
o  Selectable  low-level  hardware  and  software  instrumentation 

0  Multiple  channel  observations 

o  Correlated  data  retrieval/processing/storage 

o  Efficient  test  loop  operation. 

Note  that  test  ease  design  per  se  has  not  been  at  issue  in  this  study, 

but  rather  the  means  to  apply  and  assess  realistic,  worthwhile  test  cases. 

2.6  PREDECESSOR  HAT  ACTIVITIES 

It  is  important  to  recognize  that  this  study  has  been  constrained  by 
the  results  of  a  number  of  previous  programs,  and  that  as  a  consequence,  it 
has  sought  to  define  the  best  FIIS  options  under  the  circumstances. 
Specific  reference  applies  to  Contract  NAS2-10270,  under  which  the  ROFCS 
simulator  was  developed  for  NASA-ARC  and  the  FAA,  and  to  Contract 
NASI-15336,  under  which  the  FIU  was  developed  for  use  with  the  FTMP 
(fault-tolerant  multiprocessor)  at  NASA  LaRC.  These  two  efforts  were  not 
directly  related,  so  some  degree  of  integration  engineering  remains  to  be 
completed  after-the-fact. 

On  a  positive  note,  several  subsequent  R4T  efforts  have  contributed  to 
the  potential  realization  of  FIIS  capability.  An  FAA-sponsored  contract. 
NAS2-11‘I79,  investigated  low-level  RDFCS  hardware  fault  insertion  on  a 
limited,  manual  basis.  Then  the  FIU  was  installed  at  NAS-ARC  under 
NAS2-10832,  and  reportedly  was  checked  out  through  automated  application  of 
the  test  cases  defined  under  the  FAA-sponsored  contract.  Adding  further 
insight  into  the  use  of  the  RDFCS  facility  and  the  characteristics  of  the 
flight  control  computers  (FCCs)  is  the  independent  research  and  development 
(IRAD)  work  accomplished  there  by  the  Lockheed-Georgia  Company  in 
mechanizing  a  quadruplex  pitch  SAS  (stability  augmentation  system)  as 
described  in  Ref.  6. 

2.7  RDFCS  FACILITY  COMCERMS/FEATURES 


Overall,  the  concern  of  this  study  has  been  to  fully  utilize,  if  not 
optimize,  the  current  and  potential  FIIS  capabilities  of  the  RDFCS 
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facility.  From  the  outset,  certain  aspects  of  the  facility  were  known  to 
present  problems  or  constraints  for  the  FIIS  implementation,  and  even  now, 
some  uncertainties  remain  that  can  be  resolved  only  when  FIIS  development 
is  undertaken.  In  addition  to  the  problems  identified  in  Section  1.3,  it 
is  important  to  note  that: 


o  The  PDP-11/04  is  currently  indispensable  for  the  use  of  the 

facility,  but  it  is  a  data  flow  bottleneck  for  FITS  operation 

o  The  PDP-11/60  must  iterate  airplane  simulation  equations  of 

motions  periodically,  and  this  may  be  incompatible  with  test 
observation  time  resolution 

o  The  PDP-11/60  overhead  associated  with  disk  storage  of  test  data 
may  cause  real-time  test  loop  performance  problems 

o  The  FIU  lacks  adequate  instrumentation  and  control  features  for 
high  resolution/high  observability  testing 

o  Failure  effects  cannot  be  monitored  at  the  level  of  insertion 
(that  of  the  chip),  but  must  be  (^served  at  a  higher  level  such 
as  the  processor  bus  lines. 

These  major  concerns  have  been  addressed  in  this  study,  and 
ultimately,  they  have  been  among  the  major  deterainants  in  configuring  the 
FIIS  options.  Another  set  of  determinants  has  been  the  existing  RDFCS 
facility  features  that  are  supportive  of  FIIS  implementation,  as  discussed 
in  Section  4.1.2. 


2.8  POTENTIAL  FIIS  BEWEFITS 


Implementation  of  FIIS  capability  can  enable  certain  failure  effects 
investigations  that  have  not  (to  the  knowledge  of  the  authors)  been 
undertaken  elsewhere.  This  results  largely  from  the  high  fidelity  testing 
afforded  by  real-time  system  simulation.  There  does  exist,  however,  some 
potential  overlap  of  capability  between  the  proposed  FIIS  and  the  FTMP 
set-up  at  NASA  LaRC  (Langley  Research  Center).  To  eliminate  this,  some  of 
the  recommendations  of  this  study  should  actually  be  targeted  for  FTMP 
investigation  at  NASA  LaRC's  AIRLAB  (Avionics  Integration  Research 
Laboratory).  In  all,  the  subject  investigations  are  deemed  vital  to  the 
dependable  certification  and  deployment  of  critical  digital  flight  systems. 
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3.0  OBJECTIVES  AMD  SCOPE 


Although  the  scope  of  this  report  Is  purposefully  bounded  to  hardware 
failure  effects  investigations  suitable  for  the  RDFCS  facility,  the  study 
has  encompassed  rather  broad  objectives  in  assurance  technology.  Basi¬ 
cally,  the  overriding  concern  has  been  the  deoendable  attainment  and 
assurance  of  the  safety  of  full-time  critical  systems.  Since  the 
incidences  of  physical  faults  or  design  discrepancies  are  not  negligible, 
such  systems  must  be  capable  of  preventing  associated  undesired  effects. 
In  the  case  of  hardware  faults,  this  necessitates  the  timely  detection  and 
isolation  of  defective  elements.  Such  capability  involves  increased 
hardware  and  software  to  achieve  fault  tolerance,  and  this  in  turn 
compounds  assurance  problems.  In  any  case,  the  issue  of  fault  detection 
translates  ultimately  into  one  of  detection  coverage,  where  typically  the 
degree  of  coverage  necessary  to  meet  critical  system  reliability 
requirements  is  extremely  high. 

Since  DFCSs  are  in  general  wide  bandwidth  systems,  the  allowable  time 
to  recognize  and  isolate  a  fault  is  often  critically  short.  Fault  latency 
times  are  therefore  of  comparable  concern  with  coverage.  .In  typical 
digital  mechanizations,  a  large  number  of  faults  yield  overt  manifesta¬ 
tions,  e.g.,  complete  termination  of  processing.  Many  other  faults  that  do 
not  halt  processing  are  readily  detectable  in  a  variety  of  ways  such  as  by 
hardware  monitors  or  software  comparators.  The  faults  of  major  concern, 
however,  are  those  that  are  transient  in  nature  or  those  that  tend  to 
remain  undetected  for  a  prolonged  duration.  The  latter  class  of  faults  may 
remain  latent  until  certain  input  data,  runstream  instructions,  or 
subsequent  faults  evoke  an  anomalous  response.  Manifestation  due  to  a 
subsequent  fault  is  highly  undesirable  because  the  compound  response,  which 
has  been  neither  anticipated  nor  considered,  may  well  be  outside  of 
acceptable  limits. 

Certification  technology  is  therefore  vitally  concerned  with  the 
definition,  implementation,  and  calibration  of  fault  tolerance  provisions. 
This  concern,  moreover,  focuses  largely  on  the  definition  and  dependable 
determination  of  fault  detection  coverages  beyond  about  95  per  cent. 
Consequently,  the  major  thrust  and  objective  of  this  study  have  been 
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directed  toward  testing  methods  and  facilities  to  enable  extensive  hardware 
fault  coverage  investigations.  Since  much  of  the  fault  detection  coverage 
is  dependent  on  the  integrity  of  the  CPU,  substantial  attention  has  been 
oriented  toward  detection  of  its  failure  modes. 

3.1  ULTIMATE  GOALS 


Following  the  completion  of  this  study,  It  is  hoped  that  some  of  its 
recommendations  will  be  implemented  with  regard  to  both  system  improvements 
and  failure  effects  investigations.  The  ultimate  goal  is  that  these 
investigations  lead  to  significant  advances  in  assurance  technology, 
especially  with  regard  to  productive  test  case  application  and  interpreta¬ 
tion.  As  a  result  it  is  expected  that  these  technology  advances  will  lead 
to  the  earlier  and  assured  certification  of  full-time  flight-critical 
digital  systems. 

3.2  PaiGMATIC  OBJECTIVES 

From  a  pragmatic  standpoint,  objectives  can  be.  identified  on  two 
levels:  the  results,  of  this  study,  and  the  results  obtained  through 

carrying  out  study  recommendations.  Xn  the  case  of  the  study  itself,  the 
Intent  has  been  to  develop  FIIS  architecture  recommendations  that  provide 
the  best  capability  for  a  particular  level  of  expenditure.  This  has  been 
pursued  through  in-depth  consideration  of  the  existing  capabilities  and 
constraints  of  the  RDFCS  facility.  Further,  the  determination  of  what 
constitutes  better  capability  has  been  based  on  assessments  of  where  the 
'  most  leverage  exists  to  upgrade  certification  assurances. 

Regarding  pending  FITS  investigation  results,  the  intent  has  been  to 
foster  practitioner  confidence  in  the  test  methods  or  interpretations  to  be 
applied  or  developed.  Since  these  are  not  fully  known  at  this  time,  there 
has  been  an  effort  to  provide  an  ample  margin  of  FIIS  capability.  Further, 
there  has  been  a  commitment  to  pursue  development  of  test  methods  or 
mechanisms  that  can  readily  be  assimilated  into  Industry  practice.  Last, 
there  has  been  considerable  stress  placed  upon  the  capacity  for  generating 
clear  records  of  test  conditions  and  events  in  suitably  compact  forms. 
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3.3  STUDY  OBJECTIVES 


The  stated  objective  of  this  study  was  to  define  FIIS  architectures 
and  strategies  to  enable  generic  black  box-,  card-,  and  chip-level  failure 
effects  investigations  in  the  HDFCS  facility  at  NASA-ARC.  This  definition 
was  to  Include  implementation  requirements  and  design  approaches  that 
offered  the  most  attractive  cost/benefits  features  for  real-time  system 
simulator  investigations  of  the  following: 

o  Coverage,  latency  times,  and  general  effectiveness  of  various 

representative  DFCS  comparator  or  monitoring  schemes 

o  Quantification  of  the  extent  of  failure  effects  testing 
achievable  or  actually  achieved 

o  Definition  of  the  contributions  of  the  various  levels  of  failure 
effects  testing 

o  Development  and  assessment  of  failure  effects  testing  methods, 

with  emphasis  on  transient  phenomena,  validation  coverage,  and 
test  productivity 

o  Generation  of  empirical  or  statistical  data  for  analytical 
models. 

3.4  STUDY  OBIEMTATIOM 

Originally,  this  study  was  to  have  considered  a  minimum  of  three 
distinct  FIIS  architectures.  It  was  presumed  that  appreciably  different 
cost/benefits  would  be  present,  so  that  the  study  would  have  focused  on  the 
selection  of '  one  architecture  for  development  and  optimization.  With  the 
acquisition  of  the  FIU,  the  orientation  of  the  study  shifted  to  its  best 
utilization  and  to  compensating  for  its  inadequacies  in  the  RDFCS 
simulator. 

While  none  of  this  has  altered  the  foregoing  objectives,  it  has 
significantly  changed  the  study  tasks.  As  a  result,  the  emphasis  has  been 
on  a  family  of  FIIS  architectures  that  represent  a  logical  progression  of 
additional  facility  development  and  incremental  capability.  Each 
architectural  option  is  therefore  optimized  within  the  constraints  of  its 
allotted  resources.  Selection  of  an  option  is  in  some  respects  a  matter  of 
the  extent  of  failure  effects  Investigation  capability  that  can  be 
afforded . 
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3.5  SCOPE  OF  THE  STUDY 


As  indicated  in  Figure  1,  the  thrust  of  this  study  is  to  establish 
FIIS  design  requirements  that  provide  desired  failure  effects  investigation 
capabilities.  Furthermore,  the  rationale  as  to  the  types  of  faults  to  be 
investigated  and  the  nature  of  feasible,  worthwhile  RDFCS  facility 
modifications  are  to  be  described.  It  remains  a  follow-on  task  to  actually 
implement  the  basic  FIIS  capability,  whether  in  the  form  of  new  system 
software  or  additional  hardware. 

Once  such  capability  is  provided,  low-level  hardware  failure  effects 
investigations  can  be  performed  through  the  development  and  use  of 
applications  test  software.  Again,  the  present  study  must  anticipate  the 
associated  investigator  needs,  and  specify  their  realization  within  the 
constraints  of  the  existing  RDFCS  facility. 


^  FOLLOW-ON  FIIS 
INVESTIGATIONS 

Figure  1 .  Multi-Stage  FIIS  Development  and  Utilization 


18 


4.0  TASK  RESULTS 


4.1  PROBLEM  ANALYSIS  AND  POTENTIAL  SOLUTIONS 


The  investigations  formulated  and  proposed  in  tnis  study  are  directed 
toward  establisning  tne  effects  of  a  significant  array  of  faults  witnin  an 
FCC  processor.  Of  special  concern  is  the  relationsnip  of  particular  faults 
to  tneir  means  of  detection,  latency  times,  and  effects  on  tne  system. 
These  are  paramount  assurance  issues  for  flight-critical  digital  systems 
because  they  ultimately  determine  if  system  reliability  requirements  can  be 
met.  The  approach  taken  may  be  summarized  as  follows: 

o  Address  FAA  concerns  relative  to  digital  system  validation; 

-  monitor  coverage 

-  latency  times 

-  test  conclusiveness 

o  Pursue  generic  value,  especially  at  the  chip  and  processor  levels 

-  Results  applicable  to  other  digital  systems 

o  Ensure  conclusiveness 

-  repeatable,  encompassing,  documented  results 

0  Extend  and  better  definitize  results  obtained  under  Contract 
MAS 2-11 179 

more  faults  inserted 

-  ample,  meaningful  data  recording 

-  relevant  assessment  of  results 

o  Assure  effectiveness  and’ compatibility  of  FIIS  options 

-  worthwhile  results  with  simplest  option 

-  extended  results  with  more  sophisticated  options 

A  large  number  of  faults  have  effects  that  can  be  easily  determined 
analytically,  so  these  are  not  pursued  here.  Included  in  this  group  are 
permanent  chip  faults  such  as  to  enable  pins,  ground  pins,  and  power  pins. 
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Th«3«  faults  result  in  a  totally  inoperative  cnip,  wnicn  in  aost  instances 
causes  eitner  a  conpletely  inoperable  processor  or  loss  of  a  aajor  coKputer 
function. 

<*.1.1  FlIS  Hotlvatlon  and  iegulre—nts 

A  large  percentage  of  tne  processor  pins  can  be  readily  analyzed  fcr 
tne  effect  of  permanent  (stuck-nign  or  stuck-low)  faults,  to  tne  extent 
that  it  can  be  confidently  stated  tnat  tne  processor  will  eitr.er  produce 
obviously  erroneous  outputs  or  not  fun*tion  at  all.  Typically,  sucn  faults 
include  tnose  tnat  cause  erroneous  data  or  addresses  (eitner  data,  sacnine 
instructions,  or  microcode),  or  tnat  prevent  proper  execution  of  tne  slcrc- 
instructions.  The  detailed  process  by  wnicn  tne  obvious  effect  is  mani¬ 
fested  Is  often  dependent  on  wnen  tne  fault  Is  inserted  relative  to  tne 
flight  software  iteration  cycle.  Nonetheless  tne  analytically  identified 
overt  effect,  or  variation  thereof,  will  ultlmetely  occur  If  tne  fault  per¬ 
sists.  In  the  recommended  Inv^rstlgatlons,  persistent  faults  are  Included 
not  to  establlsn  or  confirm  tnat  processor  failure  ensues,  but  to  identify, 
document,  and  Illustrate  the  fault  propagation  process. 

The  second  type  of  fault  recommended  in  the  proposed  Investigations  is 
tne  transient  type.  These  are  recommended  for  insertion  at  random  points 
in  tne  flight  software,  with  careful  recording  of  results.  Transient 
faults  should  be  inserted  for  the  minimum  duration  possible,  and  nence  they 
tend  to  necessitate  a  full-scope  FIIS  option.  This  type  fault  also  simu¬ 
lates  pattern-sensitive  faults  that  may  remain  latent  for  a  period  of  time 
and  then  cause  erroneous  chip  output  for  one  or  more  cycles  when  certain 
input  patterns  are  present.  , 

The  Intent  to  maximize  the  generic  value  of  FIIS  investigations  moti¬ 
vates  the  emphasis  on  faulting  pins  of  the  microprocessors,  the  interrupt 
controller,  and  the  control  store  programmable  read-only  memories  (PROMs). 
The  reasoning  behind  this  Is  developed  In  the  next  section. 

The  investigations  proposed  here  would  not  be  redundant  to  the  note¬ 
worthy  results  obtained  by  McGough  and  Swern  (Ref.  7).  The  referenced  work 
Investigated  tne  fault  detection  coverage  afforded  by  explicit  built-in- 
test  (BIT)  routines  for  a  specific  avionics  processor.  The  results  were 
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obtained  sing  parallel  gate-level  emulations  of  the  subject  processor. 
Each  gate-  and  pin-level  fault  investigated  was  inserted  in  one  emulator, 
with  a  non-faulted  emulator  providing  a  reference  against  wnicn  fault 
effects  could  be  determined. 

The  BIT  procedure  investigated  in  Reference  7  included  simple  test 
problems  with  correct  answers  stored,  a  watchdog  timer  similar  to  tne  RDFCS 
interation  monitor,  memory  sum  tests,  parity  tests,  and  others.  As  each 
fault  was  emulated,  the  time  to  detection  and  means  of  detection  were 
recorded,  or  tne  fault  was  classified  as  non-detectable. 

In  the  investigations  proposed  here,  the  system  context,  including 
realistic  complete  flight  software,  is  provided  by  the  RDFCS.  The  injected 
fault  may  therefore  be  detected  by  any  of  the  full  set  of  comparators 
(e.g.,  servo  coil  current,  active  mode)  or  by  any  of  tne  intra-channel 
fault  detection  provisions  (e.g.,  bus  timeott,  iteration  monitor,  illegal 
opcode).  The  results  of  the  proposed  investigations  then  will  extend 
rather  than  duplicate  tne  Reference  7  results. 

Generic  Fault  Effect  Considerations  -  Figure  2  shows  'in  cursory  form  the 
major  functional  elements  of  one  channel  of  a  representative  DFCS.  The 
data  producers  consist  of  sensors,  other  channels  of  the  DFCS,  and  other 
aircraft  subsystems.  The  term  sensor  is  used  in  a  very  broad  sense  here  to 
include  the  inputs  from  control  panel  switches  and  control  knobs,  as  well 
as  from  accelerometers  and  gyros. 


DATA  OUTPUT 

PKOOUCEAS  _ FLIGHT  CONTROL  COMPUTER _ USERS 


Figure  2.  Dote  Flow  in  o  Representative  FCC  Chonnel 
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The  FCC  channel  shovm  in  Figure  2  assumes  autonomous  input  nandling, 
i.e.,  the  processor  is  not  involved  in  acquiring  the  incoming  data.  This 
assumption  is  made  since  autonomous  input  (and  output)  is  prevalent  in 
flight  controls  computer  design  and  will  likely  remain  so  in  the 
foreseeable  future.  The  input  data  handling  circuitry  also  transmits  a 
copy  of  the  sensor  data  to  other  channels. 

Figure  3  expands  somewhat  the  input  data  handling  function  of  Figure 
2.  The  ports  shown  may  vary  considerably,  and  each  may  be  fairly  complex. 
Ports  for  analog  inputs  may  include  hardware-implemented  pre-filters, 
signal  scaling,  and  circuits  to  convert  an  alternating  current  signal  to 
direct  current.  Ports  for  digital  inputs  may  also  be  complex,  with 
reformatting,  validity  bit  interpretation,  or  other  built-in  functions. 

A  significant  amounc  of  fan-in  occurs  in  the  block  in  Figure  3 
labelled  MULTIPLE XI MG.  Failures  in  this  block  (which  may  include  analog- 
to-digital  signal  conversion)  may  affect  several  incoming  signals,  whereas 
a  failure  in  a  discrete  port  typically  affects  only  a  single  signal.  An 
exception  is  that  of  a  port  receiving  data  from  other  channels,  in  which  a 
failure  could  cause  the  inputs  from  several  sensors  to  be  lost  in  the 


Figure  3.  Input  Data  Handling  in  a  Representative  FCC  Channel 
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receiving  channel.  Depending  on  the  particular  implementation,  some  per¬ 
centage  of  faulta  in  the  other  blocks  of  Figure  3  would  result  in  data  from 
several  data  producers  being  lost  to  the  channel  under  consideration.  The 
investigation  of  such  faults  using  the  FIIS  is  of  limited  interest,  since 
the  large  variety  of  ways  of  implementing  the  input  function  diminishes  tne 
generic  value.  Also,  the  fault  detection  mechanism  of  comparison  monitor¬ 
ing  that  is  commonly  used  in  voting  planes  is  well  understood,  so  this 
further  lessens  the  motivation  to  pursue  FIIS  investigation  of  this  func¬ 
tional  area. 

The  processor  section  is  that  functional  area  of  the  FCC  offering  the 
most  promise  for  FIIS  application.  The  basic  functional  content  of  a  hypo¬ 
thetical,  microprogrammed,  bit-slice  processor  is  shown  in  Figure  The 
interconnections  between  functional  areas  are  not  shown,  since  most  blocks 
connect  to  every  other  block. 

In  Figure  JJ,  the  microprocessors  perform  arithmetic  and  logic 
operations  in  conjunction  with  certain  supporting  circuits,  such  as  carry 
look-ahead  logic.  An  interrupt  controller  receives  incoming  requests  for 
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Figure  4.  Basic  Functional  Content  of  a  FCC  Processor 
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service  and  manages  these  cooperatively  with  the  microprocessors.  The 
microprogram  sequencer  generates  the  required  sequences  of  addresses  needed 
to  retrieve  the  microinstruction  words  from  microprogram  storage.  Sofie 
supporting  circuits,  such  as  registers  and  logic  gates,  are  also  involved 
in  selection  of  the  next  micro-instruction  address,  usually  as  the  result 

of  a  preceding  computational  step.  Bus  interface  circuitry  connects  tne 
processor  to  the  address  and  data  lines  of  the  computer.  The  clock 

produces  a  square  wave  which  provides  a  timing  reference  for  the  other 
circuits . 

Three  areas  of  the  processor  are  of  particular  interest  then  from  a 
fault-insertion  perspective;  the  microprocessors,  the  interrupt  con¬ 
troller,  and  the  microprogram  storage.  The  microprocessors  are  of  interest 
because  of  their  centrality  to  the  computation  process,  as  well  as  their 
complexity.  The-  interrupt  controller  is  of  interest  because  of  its 
internal  complexity.  Note  that  the  nature  of  the  interrupt  controller 
function  is  generic,  even  though  the  details  of  its  function  may  vary 
considerably  from  processor  to  processor. 

Similarly,  the  contents  of  the  microprogram  memory  vary  among 
processors  depending  on  the  machine-level  instruction  set,  the  details  of 
the  processor  design,  and  the  choice  of  microcode  algorithms.  Neverthe¬ 
less,  this  memory  is  of  high  generic  interest  because  the  same  algorithms 
would  probably  be  used  for  basic  arithmetic  and  logical  test  operations  in 
a  different  processor. 

Preference  of  the  three  identified  functional  areas  also  results  from 
the  fact  that  almost  any  fault  anywhere  in  the  processor  can  be  mimicked  by 
some  particular  fault  in  the  microprocessors.  Interrupt  controller,  or 
microprogram  storage.  Consequently,  faults  in  other  processor  areas  are 
de-emphasized,  but  some  shift/rotate  multiplexer  faults  have  been  included 
as  representative  of  faults  in  the  microprocessor  support  circuits. 

No  faults  have  been  included  for  the  output  handling  section  of  the 
FCC.  This  section  nas  significant  signal  fan-out,  somewnat  the  reverse  of 
the  fan-in  of  the  input  data  handling  section.  Faults  in  this  area  tend  to 
be  more  amenable  to  analy  is  than  In  the  processor,  and  of  more  predictable 
consequence . 

Memory  faults  have  not  specifically  been  included  for  evaluation  here. 
This  results  from  the  fact  that  memory  faults  which  cause  many  individual 
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data  or  instruction  words  to  be  in  error  are  manageable  in  that  they  are 
easily  detected. 

Data  memory  faults  affecting  only  a  single  data  word  are  represented 
by  the  faults  as  subsequently  identified  in  this  report  for  the  micro¬ 
processor  data  and  output  pins.  Faults  in  program  memory  which  affect  only 

a  sihgle  instruction  are  easily  detected  if  they  produce  an  invalid  op-code 
(machine  instruction  operation  code).  Those  resulting  in  a  valid  but  wrong 
op-code  can  be  more  difficult  to  detect.  These  faults  can  be  most  easily 
simulated  by  altering  the  address  during  an  instruction  fetch.  Momentarily- 
faulted  Am2901  processor  chip  output  pins  as  called  out  in  Table  4  can 
produce  such  faults.  They  can  be  explicitly  produced  if  a  suitable  means 
can  be  found  to  trigger  the  fault  during  only  a  single  instruction  fetch 
operation. 

The  following  sections  present  details  of  the  recommended  fault 
investigations.  It  should  be  noted  that  the  value  derived  from  actually 
inserting  such  faults  increases  according  to  the  sophistication  of  the  FITS 

option  used.  The  greater  results  recording  capability  of  the  more  expan¬ 

sive  options  allows  more  meaningful  evaluation  of  the  effects  of  permanent 
faults.  The  limited  duration  faults  are  of  the  greatest  value  if  the  250 
nanosecond  one-shot  multivibrator  and  the  parallel  chip  unit  (to  be 
described  later)  are  both  available. 

Microprocessor  Faults  -  The  microprocessors  are  of  particular  interest 
because  of  their  centrality  to  the  execution  of  the  flight  software. 
Additionally,  the  microprocessors  used  in  the  Collins  Adaptive  Processor 
System  (CAPS)  are  Advanced  Micro  Devices  Am2901s,  which  are  popular  for 
airborne  minicomputers,  so  consideration  of  their  failure  effects  is  of 
high  generic  value.  The  actual  extent  to  which  the  effects  would  differ 
for  some  other  processor  depends  on  the  overall  processor  organization,  the 
processor  architecture,  and  the  microcode  algorithms.  Assuming  commonly 
used  microcode  algorithms  for  numerical  computations,  the  Am29C1  output 
pins  can  be  expected  to  produce  similar  outputs  in  any  processor,  so  that 
the  effect  of  faults  affecting  only  numerical  computations  would  be  the 
same  in  any  processor. 

Mierocoded  special  functions,  tailored  for  the  needs  of  the  specific 
application,  would  tend  to  differ  among  various  processor  designs.  The 
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effect  of  a  microprocessor  fault  on  the  Am2901  output  pins  would  tnerefore 
be  of  limited  generj.c  value. 

At  the  processor  level,  the  effect  of  numerical  computations  on  the 
flight  control  laws  being  wrong  has  high  generic  interest.  The  effect  of 
wrong  microprocessor  output  on  other  processor  functions,  such  as  address¬ 
ing  machine-level  instructions  or  responding  to  interrupts,  is  very  depen¬ 
dent  on  the  number  of  such  operations  affected  as  well  as  on  the  processor 
organization  and  architecture.  Therefore,  the  areas  of  similarity  and 
difference  between  the  RDFCS  and  other  processors  must  be  carefully 
assessed  before  using  FITS  test  results  on  other  processors. 

Table  4  shows  the  faults  which  have  been  identified  for  insertion  in 
the  microprocessors.  The  results  from  Fault  Set  I  will  relate  specific 
monitoring  features  to  particular  faults.  Fault  Set  II  is  representative 
of  transient  and  intermittent  faults,  and  the  effect  of  each  may  depend  on 
When  in  the  flight  software  execution  cycle  the  faults  occur.  The  results 
from  the  application  of  these  fault  sets  can  enable  a  preliminary  statisti¬ 
cal  estimate  of  the  coverage  afforded  by  the  monitoring  mechanisms  of  the 
types  used  in  the  RDFCS. 

While  a  significant  number  of  the  permanent  faults  of  Table  4  were 
manually  Inserted  as  part  of  Contract  KAS2-11179,  they  are  called  out  for 
repetition  here  so  that  the  superior  data  recording  capability  of  the  FIIS 
can  be  used  to  Identify  more  details  of  the  fault  effects  and  to  better 
relate  the  faults  to  particular  detection  methods  and  times. 

Shift-Rotate  Hultiplexer  Faults  -  The  two  shift-rotate  multiplexer  chips 
can  also  be  of  significant  generic  Interest,  although  less  than  the 
microprocessors,  in  that  similar  functions  can  be  expected  in  other 
processors  using  Am2901s.  The  internal  logic  of  these  two  circuits  is 
straightforward,  in  contrast  to  the  Aro2901a.  Their  interaction  with  other 
circuits,  however,  can  be  a  source  of  non-trlval  complexity.  The  exact  use 
of  these  multiplexers  is  dependent  on  the  algorithms  used  for  arithmetic 
operations,  data  shifts,  and  special  microcoded  functions,  some  of  which 
may  be  quite  different  in  the  processors  used  in  other  DFCSs.  Thus,  the 
results  obtained  on  the  RDFCS  should  be  related  to  another  processor  only 
after  analytical  comparison  of  the  multiplexer  functions  and  the 
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TABLE  4.  MICROPROCESSOR  FAULTS 
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implenenting  circuitry  in  the  two  processors.  Table  5  lists  specific 
faults  reconnended  for  these  chips. 

Interrupt  Controller  Faults  -  The  Aai291‘t  interrupt  controller  used  in  the 
CAPS  processors  is  a  complex  Integrated  circuit  with  several  levels  of 
logic  between  the  input  and  output  pins.  It  includes  internal  registers 
whose  contents  affect  the  output  produced  from  a  particular  input.  Hence 
this  circuit  has  the  potential  to  display  pattern-sensitive  failure  modes. 
These  are  of  more  interest  than  the  pin-level  permanent  faults  manually 
inserted  under  Contract  NAS2-in79*  The  mo't  appropriate  approacn  to 
simulating  the  presence  of  such  faults  is  to  invert  input  bits  for  a 
minimum  length  of  time,  per  Table  6. 

It  is  anticipated  that  some  of  the  faults  in  Table  6  would  cause 
interrupts  that  trigger  an  error  routine  in  the  flight  software.  As 
currently  Implemented,  this  error  routine  traps  the  processor  in  an 
infinite  loop  if  a  bus  time-out  or  overflow  error  occurs.  This  software 
must  be  modified  to  eliminate  this  trap  in  order  to  enable  productive, 
automated  fault  insertion  investigations. 

Control  Store  Faults  -  The  40  output  pins  of  the  control  store  PROMs 
can  be  faulted  momentarily  for  a  variety  of  effects.  The  functions  of 
these  pins  are  shown  in  Figure  5.  A  large  percentage  of  the  faults  that 
could  occur  elsewhere  in  the  processor  have  the  sane  effect  as  a  control 
store  fault,  since  the  control  store  output  is  directly  involved  in  almost 
every  function  within  the  processor.  The  set  of  faults  recommended  in 
Table  7  includes  such  cases. 

It  nay  be  noticed  that  output  pins  0-8  have  been  excluded  in  Table  7. 
This  is  because  these  pins  produce  the  instruction  bits  to  the  four 
Am2901s,  with  all  four  receiving  the  sane  bit  pattern.  More  subtle  effects 
are  Judged  possible  if  the  bit  pattern  to  only  one  Am290i  is  disrupted,  as 
specified  in  Table  4. 

^e  control  store  pins  corresponding  to  bits  26-35  and  20-23  should  be 
separately  faulted  depending  on  the  usage  of  the  pins  at  the  time  of  the 
fault.  For  example,  bits  32-35  are  a  direct  "A"  port  address  for  the 
Am2901s  if  bit  15  is  1  (see  Figure  5),  and  bits  28-31  are  a  direct  "B"  port 
address  if  bits  16-17  are  11.  However,  when  the  output  08  (pin  9)  of  the 
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TABLE  5.  SHIFT'ROTATE  REGISTER  FAULTS 
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TABLE  6.  INTERRUPT  CONTROLLER  FAULTS 
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Next  Address  Control  PROM  is  low,  bits  26-35  are  routed  to  tne  microprogram 
sequencer  as  the  next  microcode  address.  Consequently,  these  bits  (pins) 
Should  be  faulted  for  each  of  their  functions  separately  to  enhance  tne 
generic  value  for  other  processors  in  which  control  store  pin  functions  are 
dedicated  rather  than  shared.  Similarly,  pins  20-23  should  be  faulted 
depending  on  their  function  at  the  time  of  the  fault. 

Results  Monitoring  -  As  shown  in  Tables  4  through  7  the  primary  data 
recording  points  .are  the  RDFCS  comparators  and  monitors.  These  merit 
Individual  discussion  as  follows: 


0  Software-Iapleaented  Monitors  -  The  RDFCS  includes  software- 

implemented  comparators  of  sensor  data.  The  flight  software  must 
be  modified  so  that  the  comparison  function  is  still  performed 
but  comparator  trips  are  Ignored.  Similarly,  software-imple¬ 
mented  servo  command  or  response  monitors  must  also  be  modified. 

.  The  occurrepce  of  each  comparator  trip  must  be  recorded,  but  tne  * 
comparator  output  must  be  either  reset  to  non-f ailed  or  ignored. 

In  a  like  manner,  mode  logic  disagreement  must  be  recorded  but 
overridden  so  that  the  system  does  not  disengage. 

o  Hardware-Implemented  Monitors  -  The  trip  of  a  hardware-imple¬ 

mented  monitor  (e.g.,  coil  current  comparator)  must  not  result  in 
system  disengagement.  The  monitor  trip,  however,  must  be  re¬ 
corded  . 

o  Iteration  Monitor  -  The  iteration  monitor  uses  both  software  and 
dedicated  hardware.  The  RDFCS  presently  has  a  provision  to  over¬ 
ride  this  monitor,  but  it  may  not  be  compatible  with  the  need  to 
observe  and  record  the  iteration  monitor  function  while 
eliminating  its  authority  to  disengage  the  servos. 

o  AWI  Commands  -  Coniaands  to  the  AFCS  (Automatic  Flight  Control 

System)  Warning  Indicator  (AWI)  should  be  monitored.  Depending 
on  the  approach  taken  to  disabling  FCC  comparators,  there  may  or 
may  not  be  any  commands  Issued.  If  the  software-implemented  com¬ 
parators  are  modified,  the  record  of  these  coennands  can  be  useful 
in  ascertaining  that  modifications  have  been  satisfactorily  made. 

o  Bus  Time-Out  and  Overflow  Interrupts  -  The  ERROR  subroutine  in 

the  flight  software  responds  to  bus  time-out  and  overflow  inter¬ 
rupts  by  placing  the  processor  in  an  infinite  loop.  This  portion 
of  the  software  must  be  modified  so  that  the  processor  resumes 
executing  the  foreground  and  background  routines,  and,  if  neces¬ 
sary,  modified  so  that  the  occurrence  of  the  interrupt  can  be 
recorded. 
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4.1.2  RDFCS  Facility  Asaessaent 


■Hie  present  RDFCS  facility  as  depicted  in  Figure  6  includes  a  Collins 
CAPS-6  based  DFCS  and  a  DEC  (Digital  Equipment  Corpor-:Mon)  POP  11 /6C 
digital  computer  for  control,  simulation,  and  evaluation.  These  elements 
are  supplemented  by  interfaces  which  allow  the  entire  system  to  perform 
simulation  and  testing  functions  in  a  high-fidelity,  real-time  reference 
frame. 

A  wide-bodied  transport  aircraft  simulation  is  presently  programmed  on 
tne  PDP  11/60  to  provide  a  number  of  representative  flight  eases  covering  a 
spectrum  of  gross  weight,  velocity,  and  altitude.  These  flight  cases  pro¬ 
vide  aircraft  configurations  for  takeoff,  climb,  cruise,  descent,  approach, 
and  landing.  In  addition,  each  simulation  case  has  ground-referenced 
geometry  for  glideslope,  localizer  tracking,  and  ground  track.  The  landing 
cases  provide  for  ground  effects  aerodynamic  coefficient  transitions.  Al¬ 
together,  the  20  available  flight  cases  provide  sufficient  coverage  of  the 
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flight  envelop*  to  utilize  all  »o4e5  of  Cne  RDfCS. 

In  addition,  there  are  tw  transitioning  aircraft  aodels  in  tne  siaju- 
lation  package.  It  is  possible  to  set  up  tne  aircraft  in  the  approach  soce 
wttn  flaps  at  22  degrees.  Wltn  a  Heading  selected,  tne  aircraft  can  cap¬ 
ture  the  localizer  beao,  engage  and  capture  tne  glideslope  beta,  ana  then 
reconfigure  itself  aerodynamically  as  tne  flaps  extend  to  33  degrees.  The 
aircraft  and  autopilot  can  tnen  proceed  into  tne  landing  and  flare  maneu¬ 
vers.  A  second  transitioning  case  provides  .''or  an  aerodynamic  reconfigura¬ 
tion  from  landing  to  takeoff  as  tne  go-around  aaneuver  is  engaged.  The 
flaps  retract  from  tne  33  degree  position  back  to  a  takeoff  position  of  22 
degrees. 

The  two  transitioning  cases  provide  an  effective  simulation  of  the 
aircraft  as  it  flies  tnrougn  two  crucial  pnases  under  control  of  the  flight 
control  system.  Windsnear  and  a  random  Oryden  gust  model  are  available  for 
introducing  external  winds  and  turbulence  into  tne  simulation.  Gust  ampli¬ 
tudes  are  specified  for  each  flight  case,  but  may  be  changed  at  the  dis¬ 
cretion  of  tne  investigator. 

For  flight  siiBulation  purposes,  tne  POP  11/60  and  tre  DFCS  are  inter¬ 
faced  tnrougn  a  Modular  Digital  Interface  Control  Unit  (MOICU),  This  unit 
provides  analog  versions  of  signals  from  the  simulation  '.or  Inputs  to  the 
FCCs  as  well  as  digitized  inputs  from  the  DFCS  to  the  simulation.  The 
MDICU  Is  interfaced  to  the  POP  11/60  through  a  serial  Manchester  encoded 
data  bus.  This  bus  Is  terminated  in  tne  POP  11/60  I/O  page  as  two  61* -word 
buffers  for  data  transmit  and  receive.  Data  transfer  is  handled  by  tne 
MDICU  and  does  not  Involve  POP  11/60  processor  interrupts. 

This  type  of  input/output  (l/D)  is  efficient  In  that  it  does  not 
require  special  action  on  the  part  of  the  real-time  routines  operating  in 
the  POP  11/60.  Incoming  data  to  tne  POP  11/60  is  stored  in  a  RAH  (random 
access  manory)  buffer  wnlch  may  be  accessed  by  any  program  mapped  to  the 
I/O  page.  Outgoing  data  from  the  POP  11/60  is  transferred  from  the  I/O 
page  to  a  first-in/first-out  (FIFO)  buffer  which  is  6**  words  deep.  A  data 
rate  of  approximately  16k  words  per  second  is  obtained  by  shifting  a  word 
out  of  tne  FIFO  every  62  microseconds.  Since  tne  data  are  Hanchester 
encoded  with  address  and  parity  bit,  the  effective  data  rate  of  tne  serial 
interface  is  357  kilobaud,  full  duplex.  Simulated  aircraft  data  can  be 
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transferred  over  the  interface  at  varying  rates  determined  by  tne 
simulation  program. 

The  MDICU  contains  an  embedded  CAPS--6  computer  wnich  could  be  used  for 
a  number  of  test  functions.  Presently  this  CAPS-6  is  used  for  scaling  and 
routing  I/O  data  to  and  from  tne  appropriate  digital-to-analog  converters 
(DACs)  and  analog-to-digital  converters  (ADCs).  Since  tne  MDICU  serves  as 
tne  I/O  processor  between  the  simulation  and  tne  DFCS,  its  rasic  functions 
must  necessarily  be  performed.  However,  it  could  be  used  for  auxiliary 
functions  such  as  limited  sensor  or  actuator  modeling. 

A  second  interface  exists  from  tne  PDP  11/60  tnrougn  tne  PDP  11/CU  to 
each  of  tne  CAPS  Test  Adapters  (CTA)  and  its  associated  CAPS-6  computer. 
Tnis  pat*  is  intended  primarily  for  control,  test,  and  analysis  of  tne 
CAPS-6  computers  from  the  PDP  11/60.  The  link  between  the  PDP  11/60  and 
".he  PDP  11/04  is  a  direct  memory  access  (DMA)  wnich  transfers  data  indepen¬ 
dently  of  the  POP  11/60  processor  once  the  transfer  is  initiated.  From  a 
PDP  11/60  program,  it  is  possible  to  perform  any  of  the  following  CTA  func¬ 
tions: 


11 

READ/WRITE 

PDP  11/04  memory 

2) 

READ 

CTK  status 

3) 

WRITE 

CTA  control  word 

4) 

READ/WRITE 

CTA  data  display  registers 

5) 

READ 

CTA  history  port 

6) 

READ /WRITE 

CTA  window. 

1)  READ/WRITE  PDP  11/04  memory  allows  blocks  of  data  to  be  trans¬ 
ferred  between  the  PDP  11/60  and  the  PDP  11/04. 

2)  READ  CTA  status  allows  monitoring  of  the  condition  of  the  CAPS-6 
processor  and  bus  for  run,  nalt,  or  error  conditions.  The  value 
of  the  history  counter  can  also  be  determined. 

3)  WRITE  CTA  control  word  allows:  control  of  the  processor  and 
transfer  bus  for  halt,  step,  and  run  conditions;  decrementing  the 
history  counter;  and  monitoring  of  break  address,  data  compare, 
or  bus  error. 

4)  READ/WRITE  CTA  data  display  registers  -  The  register  on  the  CTA 
displaying  the  current  address,  data  and  keyboard  can  be  moni¬ 
tored  and  changed  from  the  PDP  11/60. 
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5)  READ  CTA  history  port  -  The  CTA  contains  a  TRANSFER  BUS  HISTORY 
buffer  into  which  is  deposited  the  contents  of  the  status, 
address,  and  data  registers  for  the  16  nost  recent  bus  opera- 
tions.  The  contents  of  these  buffers  are  available  to  programs 
running  on  the  POP  11/60.  The  transfer  bus  is  automatically 
halted  when  a  READ  HISTORY  PORT  Is  initiated. 

6)  READ/WRITE  CTA  window  -  The  Unibus  in  tne  PDP  11/04  is  connected 
to  the  transfer  bus  in  each  CAPS-6  computer  by  a  high-speed  data 
window  in  which  a  MOVE  instruction  in  the  PDP  11/04  is  auto¬ 
matically  transferred  into  a  similar  operation  in  the  CAPS-6  at  a 
preselected  address.  This  is  an  extremely  powerful  device  in 
that  it  gives  programs  in  the  PDP  11/60  direct  access  to  the 
entire  memory  of  eacn  CAPS-6  computer.  Thus,  a  PDP  11/60  program 
can  read  and  modify  data  or  instructions  in  the  CAPS  memory. 

All  of  these  CTA  operations  can  be  performed  by  the  PDP  11/04  acting 
as  a  peripheral  processor  to  the  PDP  11/60.  Except  for  initialization,  all 
lata  transfer  between  tne  PDP  11/60  and  tne  PDP  11/04  is  accomplished  by 
standard  NPR  (non-processor  request)  data  transfers  and  operates  on  a 
cycle-steal  basis  so  that  the  overhead  of  processor  interrupts  is  mini¬ 
mized. 


A  number  of  growth  provisions  exist  in  the  present  facility.  While 
these  features  may  not  affect  the  implementation  of  the  FITS  directly,  they 
should  permit  higher  quality  results  to  be  obtained  as  faults  are  intro¬ 
duced  and  the  subsequent  failure  results  are  monitored.  Since  the  feasi¬ 
bility  of  transitioning  flight  simulation  using  state  models  has  already 
been  demonstrated,  it  might  be  desirable  to  have  an  aircraft  capable  of 
transitioning  toward  several  corners  of  the  flight  envelope  to  provide  a 
realistic  assessment  of  dynamic  performance  in  the  event  of  a  critical 
failure  in  the  flight  control  system.  This  transitioning  capability  can  be 
accomplished  by  determining  the  coefficients  of  incremental  forcing  func¬ 
tion  matrices  during  the  initialization  phase  and  solving  these  matrices  in 
real  time. 

In  a  similar  manner  it  should  be  possible  to  incorporate  various  non¬ 
linear  effects  such  as  stall  characteristics  at  high  angles-of-attack. 
Second-order  non-linear  effects  can  normally  be  introduced  as  additional 
state  forcing  function  matrices  with  greatly  improved  simulation  fidelity. 
The  present  transitioning  simulation  requires  approximately  7.5 
milliseconds  per  cycle  at  50  cycles  per  second.  This  leaves  approximately 
12.5  milliseconds  for  additlonanl  computation  including  system  overhead  and 
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context  switching.  As  sparse  matrices  are  Incorporated  into  the  simulation 
to  handle  the  non-linear  effects,  it  becomes  practical  to  consider  computa¬ 
tional  enhancements  such  as  provided  by  an  array  processor  operating  from  a 
host  PDP  11/60.  The  total  matrix  developed  in  this  manner  becomes  banded 
and  is  ideally  suited  for  array  processing.  A  unique  feature  of  this  con¬ 
cept  is  that  as  the  simulation  becomes  increasingly  complex, the  computation 
becomes  more  efficient. 

A  further  refinement  of  the  airplane  simulation  would  be  the  addition 
of  landing  gear  dynamics  to  allow  the  DFCS  to  follow  through  the  landing 
phase  into  the  roll-out  mode.  High  fidelity  simulation  of  gear  dynamics 
normally  involves  extremely  high  frequencies  due  to  the  dynamics  of  the 
unsprung  mass  in  real  time.  However,  if  these  effects  are  filtered  out  so 
that  only  the  lift  decay  is  considered  as  the  aircraft  settles  on  the 
landing  gear  and  enters  the  rollout  mode,  it  should  be  possible  to  reason¬ 
ably  simulate  the  rollout  effects.  The  transition  from  an  aircraft  sus¬ 
pended  aerodynamically  to  one  supported  by  the  landing  gear  requires  that 
the  simulation  snift  between  two  entirely  different  dynamic  models.  This 
requires  a  real-time  program  on  the  POP  It/60  which  would  be  considerably 
more  complicated  than  the  present  linearized  simulation.  However,  to 
utilize  the  FIIS  for  fault  investigations  in  this  critical  landing  maneuver 
requires  a  more  sophisticated  simulation  than  that  currently  available. 

Another  area  having  a  strong  influence  on  the  application  of  the  FIIS 
la  the  Interface  from  the  PDP  11/60  to  the  CTA  via  the  PDP  11/04.  If  it 
becomes  desirable  to  either  enhance  the  simulation  on  the  PDP  11/60  or 
handle  large  quantities  of  data  through  the  CTA  window  to  a  CAPS  transfer 
bus,  then  a  different  control,  data  handling,  and  data  analysis  concept 
should  be  considered.  The  PDP  11/04  used  as  the  int<.  mediate  processor  in 
the  PDP  11/60-CTA  link  is  the  lowest  performing  processor  in  the  PDP  11 
series.  It  may  be  desirable  to  replace  the  present  data  link  with  a  stand¬ 
alone  Unlbus  type  processor  that  is  capable  of  handling  the  FIIS  analysis. 
With  a  stand-alone  system,  large  amounts  of  data  could  be  transferred  to  a 
bulk  storage  medium  without  Interferring  with  the  simulation  running  on  the 
PDP  11/60. 

While  the  RDFCS  simulator  provides  a  good  representation  of  a  trans¬ 
port  type  aircraft  operating  with  a  DFCS,  certain  conditions  may  arise 
during  FIIS  utilization  that  might  yield  fallacious  results.  The  aircraft 
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model  is  linearized  about  a  point  of  constant  velocity  and  dynsnic  pres¬ 
sure.  Vfhile  the  performance  around  the  operating  point  has  reasonably  high 
fidelity,  as  the  system  is  driven  away  from  this  point  the  flight  charac¬ 
teristics  tend  to  deviate  from  the  norm.  An  induced  fault  which  causes  an 
abrupt  nose-qp  condition  during  a  landing  or  go-around  maneuver  might  yield 
non-realistic  effects  because  the  aircraft  model  does  not  exhibit  proper 
stall  characteristics  at  the  present  time.  An  abrupt  nose-up  cotonand  from 
a  malfunctioning  DFCS  system  would  cause  increased  lift  with  a  resultant 
gain  in  altitude,  rather  than  having  the  lift  decrease  and  altitude  loss  as 
a  result  of  typical  stall  conditions.  If  stall  characteristics  are  an 
important  aspect  of  any  of  the  FIIS  investigations,  then  they  should  be 
built  into  the  aerodynamic  model. 

Another  limitation  of  the  facility  is  the  necessity  of  manual  engage¬ 
ment  of  the  DFCS  after  the  aircraft  is  in  a  flying  mode.  In  order  to 
activate  the  DFCS  system,  the  bat  handles  on  the  glareshield  control  panel 
must  be  raised,  the  autothrottle  must  be  engaged,  and  then  the  proper  auto¬ 
pilot  mode  must  be  selected.  While  this  sequence  of  operations  is  directly 
analogous  to  the  actual  flight  procedures,  it  introduces  an  element  of  time 
uncertainty  with  each  run  that  is  made.  Therefore,  some  dispersion  in  the 
results  may  occur  among  different  runs  when  the  FIIS  is  being  used.  It  may 
be  virtually  impossible  to  introdme  faults  into  the  system  so  that  the 
fault  occurs  at  a  precise  or  consistent  point  during  the  flight  maneuver  or 
at  a  preselected  point  in  the  DFCS  execution  cycle. 

When  the  RDFCS  simulator  facility  was  originally  conceived,  it  was 
anticipated  the  various  components  would  be  physically  situated  at  remote 
distances  from  each  other.  A  fiber  optic  link  was  anticipated  to  provide 
low  noise  serial  communication  between  the  PDF  11/60  and  the  HDICU.  The 
fiber  optic  link  never  provided  reliable  performance  and  was  replaced  by  an 
electrical  serial  link,  with  the  POP  11/60  and  the  MDICU  being  in  close 
proximity.  The  MDICU  serial  link  is  controlled  internally  and  does  not 
require  interaction  by  the  POP  11/60;  however,  serializing  the  data  does 
Introduce  a  measurable  phase  lag  between  the  simulation  model  and  the  DFCS 
system.  This  lag  should  be  considered  in  the  analysis  of  data  obtained  as 
a  result  of  inserted  faults. 

Another  major  limitation  of  the  system  is  the  speed  of  the  PDP  11 /OH 
processor  in  accessing  the  CAPS  transfer  bus  via  the  CTA  window.  While  the 
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PDF  11/04  relieves  the  PDP  11/60  of  processor  I/O  to  the  CTA  window,  it  is 
extrCTely  slow  and  has  no  provision  for  bulk  storage.  Data  collected  as 
part  of  a  fault  insertion  analysis  must  be  transferred  over  the  DMA  inter¬ 
face  and  stored  in  PDP  11/60  memory  while  real-time  simulation  is  taking 
place.  It  cannot  be  downloaded  onto  the  disk  during  real  time  because  of 
the  block  transfer  time  requirements  of  the  disk. 

While  a  number  of  limitations  have  been  cited,  it  should  not  be  con¬ 
cluded  that  the  RDFCS  simulation  facility  is  not  a  powerful  tool  for 
analyzing  both  hardware  and  software  DFCS  failure  effects.  The  simulator 
provides  a  great  deal  of  flexibility  in  introducing  faults  and  analyzing 
these  effects  as  long  as  the  system  limitations  are  properly  understood  or 
appropriate  modifications  made. 

4.1.3  Potential  Testing  Schemer 


A  model  of  failure  effects  testing  as  presented  in  Figure  7  begins 
with  the  definition  of  test  cases.  These  establish  the  aspects  of  tne  DFCS 
to  be  examined  and  the  facilities  needed  to  perform  the  testing.  Automated 
and  arbitrary  control  of  fault  injection  enables  the  application  of  an 
appropriate  range  of  test  stimuli  to  the  FCC,  and  if  desired,  to  a  fault 
model  that  serves  in  the  interpretation  of  test  results.  The  fault 
injector  (FI)  also  controls  a  precise  clock  used  to  measure  fault  latency 
times  that  are  associated  with  various  fault  detection  mechanisms.  The 
low-level  instrumentation  needed  for  definitive  testing  is  implemented  in 
both  hardware  and  software,  and  test  results  processing  is  normally 
performed  in  the  test  control  computer. 

In  implementing  and  using  such  a  test  scenario,  the  major  concern  is 
that  of  obtaining  needed  resolution  in  the  application  of  stimuli  and  the 
timing  of  responses.  Coordination  of  the  total  test  loop  is  therefore  of 
pivotal  importance.  Time  delays,  skewing,  and  indeterminacies  must  be 
effectively  eliminated,  and  this  necessitates  adequate  data  rates  and  pro¬ 
cessing  capacities  throughout  the  loop.  Some  tradeoffs  do  exist,  e.g., 
processor  throughput  suitably  located  can  alleviate  data  rate  or  storage 
requirements.  In  a  very  limited  sense,  such  a  tradeoff  indicates  the  broad 
range  of  possibilities  in  configuring  a  FIIS  to  enable  the  teat  scenario  in 
Figure  7.  In  an  optimized  Implementation,  the  balanced  and  economical  use 
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Figure  7,  Idealized  Failure  Effects  Testing  Scenario 


of  resources  is  a  fundamental  guideline*  and  the  ultimate  measure  of 
success  is  the  resultant  level  of  capability. 

4.1.4  Fault  and  Failure  Detection  in  the  HDFCS 


The  fault-failure  detection  provisions  used  in  the  RDFCS  Include  soft¬ 
ware-  and  hardware-implemented  monitors.  These  are  used  to  detect  sensor 
faults,  computer  faults,  or  lack  of  proper  servo  response. 

Although  the  RI^CS  contains  only  simulated  sensors,  the  FCCs  include 
sensor  monitoring  functions  suitable  for  use  in  an  actual  airborne 
autopilot.  The  signals  from  triple  and  quadruple  sensors  are  compared  and 
voted  in  software  prior  to  use,  with  each  of  the  four  computer  channels 
performing  the  comparison  and  voting  on  the  signals  it  will  use  in  control 
law  computations.  This  permits  faults  in  the  data  input  section  of  a 
computer  channel  to  be  detected  as  well  as  faults  in  the  sensors 
themselves.  The  sensor  signals  are  monitored  Just  prior  to  use,  so  a 
signal  which  will  not  be  used  is  not  compared.  For  example,  pitch  attitude 
is  monitored  and  used  in  cruise  autopilot  vertical  modes,  but  pitch  rate  is 
neither  used  nor  monitored.  During  an  automatic  approach,  the  control  laws 
use  pitch  attitude  rate  instead  of  pitch  attitude,  and  so  pitch  rate  moni¬ 
toring  begins  and  pitch  attitude  monitoring  ends  upon  engagement  of  the 
Approach/Land  Track  submode  of  autopilot  operation. 

The  triple  and  quadruple  sensors  also  produce  discrete  validity 
signals  which  are  monitored  by  software  within  each  FCC  channel,  so  that  an 
individual  sensor  signal  will  not  be  used  if  it  does  not  compare  closely 
with  others  of  the  same  type  or  if  the  associated  validity  signal  is  not 
present. 

Dual-dual  and  quadruple  sensors  are  comparison-monitored  in  the  same 
way,  but  the  response  to  a  fault  is  different.  Up>on  detection  of  tne  first 
fault  in  a  quadruple  sensor  set,  the  other  three  sensors  are  treated  as  a 
triple  sensor,  with  the  bad  sensor  excluded  from  further  use.  The  dual¬ 
dual  sensors  have  hlgh-integrity  self-monitoring,  which  is  relied  upon 
particularly  for  detection  of  a  second  fault.  When  a  single  side  of  a 
dual-dual  sensor  is  detected  faulty,  the  entire  sensor  is  condemned,  with 
the  two  outputs  from  the  other  sensor  compared  for  disagreement  for  the 
remainder  of  the  flight.  Since  the  only  dual-dual  sensors  are  the 
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Instrument  Landing  Syst«n  receivers  and  the  radio  altimeters,  union  are 
used  only  In  approach  and  landing,  the  duration  of  the  flight  segment  is 
the  short  time  to  touchdovm  from  an  altitude  of  1500  feet  or  less. 

Sensor  data  coming  into  the  FCCs  are  handled  by'  autonomous  input 
nandling  hardware.  The  sensor  monitoring  functions  can  detect  failures  of 
this  hardware  unich  cause  one  or  more  sensors  to  appear  faulted  to  the 
computer,  faulty  sensor  wiring,  and  actual  sensor  faults.  This  monitoring 
cannot  detect  program  memory  faults,  other  than  those  wnich  cause  the 
sensor  data  to  be  read  from  a  valid  but  wrong  address. 

IXjring  operation,  the  processor  is  continually  checked  for  its  ability 
to  execute  its  instruction  set,  program  memory  is  checked,  and  the  repeated 
execution  of  the  foreground  loop  is  monitored.  The  specific  fault  detec- 
tiOT  methods  used  are  as  follows. 

CPU  Diagnostie  -  The  CPU  diagnostic  routine  is  allocated  time  in  the  back¬ 
ground  mode  every  200  msec.  Each  machine-level  instruction  used  elsewhere 
in  the  flight  software,  other  than  those  which  would  interfere  with  system 
operation  (e.g.,  CLEAR -CLOCK),  is  executed  with  the  result  compared  to  the 
proper  result.  Failure  of  the  processor  to  produce  the  correct  result  for 
any  instruction  causes  autopilot  and  yaw  SAS  servo  disengagement.  The 
diagnostie  program  also  produces  a  count  of  the  number  of  Instructions 
tested.  The  foreground  software  monitors  the  number  of  instructions  exe¬ 
cuted  since  the  previous  time  the  counter  was  checked.  If  the  counter  does 
not  have  the  correct  value  or  does  not  change  for  120  seconds,  a  failure  is 
declared  in  the  foreground  software  and  the  corresponding  FCC  channel 
disengages. 

Checksums  -  Each  PROM  card  has  stored  in  its  first  two  i 6-bit  addresses  the 
32-bit  sum  of  the  contents  of  all  other  addresses  on  the  card.  The  con¬ 
tents  of  each  of  these  other  addresses  is  added  and  if  the  sum  does  not 
equal  the  contents  of  the  first  two  addresses,  a  failure  is  declared  and 
the  FCC  channel  disengages.  The  foreground  software  declares  a  failure  if 
more  than  20  seconds  elapse  since  the  last  successful  checksum  test  of  any 
card. 

Iteration  Monitor  -  In  each  channel,  the  foreground  executive  software 
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module  executes  every  50  msec  through  one  of  4  paths.  Bit  15  of  a  data 
word  written  to  a  specific  hardware  address  is  set  FALSE  at  the  beginning 
of  paths  1  and  3  and  set  TRUE  at  the  beginning  of  paths  2  and  U.  The 
status  of  this  bit  is  continuously  output  as  an  electrical  signal,  so  that 
a  10  Hertz  (Hz)  square  wave  is  produced  when  the  software  is  being  executed 
normally.  Dedicated  hardware  in  each  channel  monitors  the  presence  of  the 
10  Hz  wave,  which  is  required  for  servo  engagement. 

Path  Monitoring  -  Each  channel  also  compares  its  foreground  path  number  to 
that  of  the  other  channel  in  the  same  box,  and  disagreement  causes  the  FCC 
channel  to  disengage.  Path  number  monitoring  is  discontinued  in  the 
Approach/  Land  track  submode  of  operation. 

Wrap-Around  Teat  -  Flight  director  (FD)  commands  are  wrapped-around  to  both 
channels  of  each  FCC,  Wrap-around  failure  in  either  channel  results  in  a 
bias  to  hold  the  FD  command  bars  out  of  view. 

Servo  Co—and  Monitoring  -  Servo  commands  for  roll,  pitch,  or  yaw  are  com¬ 
parison  monitored  in  hardware.  IXial  coil  current  comparators  monitor  the 
outputs  from  both  channels  of  each  FCC.  Disagreement  by  any  comparator 
will  cause  either  yaw  SAS  or  roll  and  pitch  servo  disengagement,  as  appro¬ 
priate.  Servo  rate  is  also  monitored  in  hardware  for  the  pitch  axis. 
Servo  modulator  piston  position  is  monitored  in  software  for  the  roll  and 
yaw  axes. 

Bua  Activity  -  The  FCC  software  includes  monitors  to  ensure  that  sensor 
data  and  cross-channel  data  are  being  updated  at  the  required  rate. 

Control  Panel  Bus  -  The  digital  bua  to  the  control  panel  is  tested  by 
circulating  teat  words.  Periodically,  one  of  three  such  words  is  trans¬ 
mitted  by  the  FCC.  If  it  does  not  receive  this  word  back  from  the  control 
panel  within  the  prescribed  time,  a  bus  failure  is  declared,  and  further 
commands  from  that  panel  are  ignored. 

Cross-Channel  Mode  Agreement  -  Each  channel  periodically  transmits  its  mode 
status  to  the  other  channel  in  the  ssoie  FCC,  If  these  disagree  for  more 
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than  one  iteration  of  the  foreground  software  in  either  channel,  the  soft¬ 
ware  withdraws  its  enable  input  to  the  servo  engage  logic. 

Arlth»etic  Overflow  -  If  the  result  of  an  arithmetic  computation  overflows, 
the  microprocessor  handling  the  high-order  bits  sends  a  high-priority 
interrupt  request  to  the  interrupt  controller.  If  not  masked,  this  causes 
the  interrupt  controller  to  initiate  the  interrupt  handling  sequence,  which 
in  turn  results  in  the  software  branching  to  an  infinite  nil  loop.  Dis¬ 
agreement  then  results  for  one  of  several  reasons:  iteration  monitor  trip, 
mode  disagreement  disconnect,  coil  current  comparator  trip,  etc. 

Illegal  Opcode  -  An  attempt  by  the  processor  to  use  a  stack  area  which  is 
outside  of  the  allocated  address  range  will  result  in  a  high-priority 
interrupt.  As  in  the  ease  of  arithmetic  overflow,  the  software  enters  the 
infinite  nil  loop  and  the  servos  disengage. 

Bua  Tiaeout  -  A  bus  time-out  error  occurs  if  the  processor  attempts  to 
address  a  non-existent  memory  address.  This  has  the  same  effect  as  the 
arithmetic  overflow  and  illegal  opcode  errors  just  discussed. 

<.2  CAWDIDATE  FITS  ARCHITECTURES 


Under  this  section,  candidate  FIIS  architectures  are  defined  and  pro¬ 
posed  to  improve  the  capabilities  of  the  RDFCS  to  support  low-level  failure 
effects  testing.  The  FIIS  options  are  partitioned  into  the  following  four 
progressively  enhanced  categories: 

o  Existing  system  with  only  software  modifications 

o  Improved  system  with  a  combination  of  software  and  modest  hard¬ 
ware  modifications 

o  Advanced  system  based  on  extensive  modifications 

o  Superior  system  based  on  the  full  scope  of  feasible  modifica¬ 
tions. 

All  proposed  system  architectures  are  upward  compatible  and  are  based 
on  the  use  of  the  Draper  FIU  for  accomplishing  the  fault  insertion 
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function.  The  Intent  of  all  of  the  proposed  FIIS  architectures  is  to 
provide  improved  low-level  fault  insertion  and  instrumentation  capability 
that  supplements  the  existing  FIU  features.  Because  it  constitutes  the 
greatest  current  need,  the  emphasis  here  is  largely  on  instrumentation. 
The  first  of  the  proposed  FIIS  options  consists  only  of  the  addition  of  new 
software  to  enhance  the  existing  facility.  The  software  to  be  added 
enhances  the  existing  capability  by  the  addition  of  a  FIIS  executive  in  the 
PDF  11/60  that  would  give  the  user  access  to  the  extended  capabilities  to 
be  offered  by  new  test-related  software.  Such  features  would  include  FI 
initialization,  fault  insertion  control,  extended  DMA  capability  to  the 
CTAs,  and  PDP  11/60  results  processing. 

The  second  proposed  FIIS  option  consists  of  the  addition  of  custom 
hardware  that  would  passively  monitor  and  record  the  CAPS  transfer  bus 
transactions  in  cache  memory.  A  bus  monitor/ recorder  unit  (BMRU)  would 
also  contain  a  clock  for  fault  detection  timing  measurements,  receive  and 
decode  interrupts  from  the  FCCs  in  the  pallet,  and  interface  to  tne  PDP 
11/60  via  a  DMA  data  link. 

Tne  third  candidate  architecture  includes  a  PDP  tt/24  minicomputer  to 
replace  the  much  slower  PDP  11/04.  A  BMRU  similar  to  the  one  described 
under  FIIS  Option  TWo  would  be  used  to  capture  CAPS  transfer  bus  trans¬ 
actions  for  later  analysis  by  the  POP  11/60.  A  system  clock  would  also  be 
added  for  better  measurement  of  fault  detection  times  under  this  higher 
performance  and  resolution  system. 

The  fourth  FIIS  option  builds  upon  the  capabilities  described  under 
the  first  three  systems,  coupled  with  the  addition  of  sophisticated  Hard¬ 
ware  for  pin-level  instrumentation.  A  unit  for  paralleling  two  of  the  same 
chips  is  proposed  that  would  allow  conclusive  determination  of  whether  an 
injected  fault  propogates  to  the  output  pins  of  the  device  under  test. 
Another  proposed  unit  is  a  logic  state  recorder  that  would  have  the  capa¬ 
bility  to  selectively  monitor  and  record  the  states  of  various  pins.  This 
information  could  then  be  analyzed  by  the  PDP  11/60. 

4.2.1  Option  One;  Software  Modified  System 

As  indicated  in  Figure  8,  the  first  FIIS  architecture  defined  is  com¬ 
posed  of  the  existing  RDFCS  facility,  including  the  Draper  FIU,  and  new 
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programs  written  to  upgrade  the  capability  to  control  the  insertion  of 
simulated  faults  and  to  record  results  and  timing  information.  The 
specific  software  to  be  added  is  sunaarized  in  Table  8.  The  following 
elaborates  the  functions  of  the  various  modules  listed  in  the  table. 

PDF  11/60  Software  -  The  software  structure  for  tne  POP  I 1/60  minicomputer 
additions  is  Illustrated  in  Figure  9.  The  FIIS  executive  is  the  Interface 
to  the  expanded  functions  proposed  to  support  low-level  testing  utilizing 
the  Draper  FIU  on  the  RDFCS  facility.  The  executive  is  partitioned  into 
initialization  and  results  processing  (non-realtime)  modules  and  a  real¬ 
time  control  section  for  test  case  execution.  Referring  to  Figure  9»  the 
non-realtime  routines  consist  of: 

o  Draper  FI  initialization 
o  POP  11/04  Initialization 

o  Aircraft  model  initialization  (already  existing) 
o  Results  processing. 
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TABLE  8.  NEW  SOFTWARE  MODULES  FOR  OPTION  1 


POP  11/40 

POP  11/04 

CAPS-hS 

•  CONTROL  ROUTINES  FOR 
DRAPER  FlU 

•  DATA  BUFFERING 

ROUTINE 

a  background  TEST  EXECUTION 
MONITOR  PROGRAM  USING 

EXCESS  CORE  MEMORY 

•  EXPANDED  CONTROL 
ROUTINES  FOR  POP  1 1/134 

•  EXPANDED  DATA 
COLLECTION 

•  GENERATION  OF  INTERRUPT 

SIGNAL 

•  RESULTS  PROCESSING 

•  DR  ll-C  INTERFACE 

DRIVER 

•  SYSTEM  CONTROL 
PRC3GRAM 

1 

POP  11/40  PUS 
SXECUTIVE 


DRAPES  FI 
INITlALirATlCN 


POP  11/tA 
INITIAU2ATION 


PALLET  AlRPUNE  MODEL 

CONTROL  INITIALIZATION 


RESULTS 

PROCESSING 


1 

POP  1 1/04  DATA 

! 

FAULT 

1 

MODEL 

1 

INTERRUPT 

REAL-TIME 

LINK  management 

INSERTION/ 

EXECUTION 

HANDLER 

RESULTS 

REMOVAL 

PROCESSING 

Figure  9.  PDP-il/60  FIIS  Software  Structure 


After  initialization  of  the  test  sequence  ir  accomplished,  the  execu¬ 
tive  begins  real-time  execution  of  the  following  routines; 


o  Interrupt  handling 

o  Fault  insertion/removal  (Draper  version  existing  now  in  PDP-11/60) 
0  PDP  11/04  data  link  management 

o  Aircraft  model  (already  existing) 

0  Real-time  results  processing. 
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Th«  following  details  tne  functions  perforaed  tjy  eacn  of  tne  proposed 
new  software  modules: 


o  FIIS  Executive  -  The  FIIS  executive  would  be  tne  priaary  user 
interface  to  tne  new  FIIS  software  tnat  supports  low-level 
testing  on  the  RCFCS  facility.  In  addition  to  controlling  tne 
non-realtime  and  real-time  functions  outlined  above,  tne 
executive  would  also  nave  tne  capability  to  start,  stop,  and 
reset  tne  FCCs  on  tne  pallet,  as  well  as  to  start  and  stop  strip 
Chart  recorders.  These  two  functions  would  be  provided  by  using 
spare  digital-to-dlscrete  (D/D)  converters  in  tne  HDICU.  Tnis 
would  require  only  tne  addition  of  new  wiring  to  tne  pallet.  The 
FIIS  executive  would  be  designed  to  simplify  test  case  definition 
and  to  provide  for  efficient  test  case  execution.  The  executive 
would  nave  tne  capability  to  store  a  sequence  of  test  cases  to  be 
executed  in  order  t*  alleviate  redefining  new  parameters  for  eacn 
test  case  executed.  Automated  testing  may  tnen  be  achieved  by 
overriding  tne  bathandle  logic  in  tne  flight  software.  It  may  be 
necessary  to  provide  a  mechanism  to  reload  tne  fllgnt  software 
after  execution  of  particular  test  cases,  and  tnis  could  be 
acnleved  by  using  tne  PDr  n /Ott  under  control  of  tne  POP  i*. /6C  to 
transfer  the  flight  software  between  FCC  cnannels. 

0  Draper  FI  Initialization  -  The  initialization  program  for  tne  FI 
would  provide  the  commands  necessary  to  define  the  faults  to  be 
Injected  In  tne  FCC  under  test  during  real-time  operation.  The 
functions  to  be  made  available  would  be  tne  ones  described  in 
Draper  Report  CS!X-fl-l602  (Ref.  8)  plus  cosnands  specific  to  tne 
RDFCS  facility.  These  are  summarized  in  Table  9. 

o  POP  11/Oft  Initialization  -  The  POP  11/Oft  initialization  program 
would  allow  the  definition  of  tne  memory  locations  in  the  FCCs  to 
be  monitored  by  tne  POP  11 /Oft  during  test  case  executicxi.  This 
Information  would  be  stored  for  use  by  the  POP  11 /Oft  data  path 
management  program  which  executes  in  real  time  for  tne  actual 
data  transfer. 

o  Interrupt  Handler  -  This  real-time  program  would  be  used  to  ser¬ 
vice  interrupts  generated  by  tne  FCCs  in  the  pallet.  The  program 
would  decode  the  four  Interrupt  lines  (one  from  eacn  cnannel)  to 
determine  whicn  FCC  initiated  tne  Interrupt.  This  information 
would  then  be  used  as  dictated  by  the  test  case  definition.  One 
possible  use  mignt  be  to  signal  tne  POP  ii/60  tnat  tne  Injected 
fault  has  been  successfully  detected  by  the  CAPS-6.  By  reading 
the  real-time  clock  in  the  POP  11/60  at  the  time  of  fault  injec¬ 
tion  and  again  when  the  interrupt  occurs,  a  rough  order-of-magni- 
tude  measurement  of  the  fault  detection  time  could  be  obtained. 

o  Fault  Insertion/Removal  -  Tnis  real-time  program  would  be  used  to 
control  the  actual  fault  injection  and  removal  by  the  FI.  Fault 
injection  and  removal  could  be  accomplished  as  a  function  of: 
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TABLE  9.  FlU  COMMANDS 


* 

Consiaad 

1 

Function  { 

! 

Defias  Uaa  H 

i 

This  command  defines  an  M  pin 
Integrated  Circuit  (IC)  whose 
designation  is  Unn  on  the  board 

Map  n  AM  1 

This  command  maps  the  XC 
under  test  to  the  appropriate 

FID  multiplexer  1 

Describe  n  abed 

This  command  describes  the 

fault  abed  to  be  injected  into  j 

pinnot  the  IC  under  test  1 

Furc  abed 

1 

! 

This  command  is  used  to  select 
the  boolean  function 

Enable  a 

This  command  selects  pin  n 
of  the  IC  and  enables  the  unit 
for  fault  injection 

Disable  a 

This  command  disables  pin  n  of 
the  IC  under  test  for  fault 
injection 

Exe  c  a 

This  command  injects  the  fault 
for  n  seconds 

Transient 

This  command  causes  the 

POP  11/60  to  inject  the  fault 
and  then  immediately  remove 
it  ('>'6  msec  elapsed  time) 

Inject  Ion 

This  command  injects  the  fault 
as  a  function  of  the  aircraft  model 
parameter  1  where  m  is  either  equal 
to,  greater  than,  or  less  than  and 
n  is  the  reference  value 

Pulse  m  n 

This  command  causes  the  fault  to 
be  turned  on  at  m  second  intervals 
and  left  on  for  n  seconds  (Note  m 
must  be  greater  chan  n) 

-  User  initiated  from  POP  11/60  terminal 

-  POP  1 1 /60  real-time  clock 

-  Aircraft  model  parameters 

-  Pallet  parameters 

0  through  interrupts 
0  through  POP  11/04  data  path. 


An  example  of  fault  injection  and  removal  might  be  the  injection 
of  fault  at  the  automatic  landing  decision  height  (aircraft  model 
parameter),  followed  by  its  removal  five  seconds  later  or  upon 
receiving  an  interrupt  from  the  FCC  indicating  detection  of  tne 
fault . 

o  Results  Processing  -  Results  processing  would  be  implemented 
through  both  real-time  and  non-realtime  functions.  The  real-time 
processing  would  be  limited  to  the  annunciation  of  certain  key 
events,  e.g.,  notification  that  a  fault  was  injected  or  that  an 
Interrupt  from  the  pallet  was  received.  The  non-realtime  pro¬ 
cessing  would  be  test  ease  dependent,  but  would  include  automated 
report  generation  and  plotting  capability. 

PDP  11/04  -  The  software  modifications  proposed  for  the  PDP  11/04  would 
consist  of  expanding  the  functions  that  the  POP  11/04  could  perform,  and  of 
increasing  the  amount  of  test  data  that  could  be  transferred  over  the  data 
path  from  the  PDP  11/04  to  the  POP  11/60.  Software  would  be  added  to  the 
PDP  11/04  that  could  allow  it  to  poll  a  s-;*  vf  CAPS-6  addresses  tnat  were 
designated  by  the  PDP  11/60  during  test  case  initialization.  These  data 
would  then  be  buffered  by  the  PDP  11/04  for  transfer  to  the  PDP  11/60  for 
results  analysis  after  termination  of  the  test  case. 

The  other  modification  to  the  PDP  11/04  would  be  to  increase  the 
amount  of  data  transferred  from  the  current  512  word  limit  to  2048  words. 
These  data  can  be  transferred  at  a  rate  of  approximately: 


100  sec  +  (20  ^see  per  word  transferred) , 

CAP3-6  -  Two  modifications  would  be  made  to  the  flight  software  in  the 
FCC?  Both  modifications  would  be  test  case  dependent  to  some  extent.  The 
first  modification  would  be  the  addition  of  a  test  execution  monitor  pro¬ 
gram  that  runs  in  the  background  mode  and  uses  the  excess  core  memory 
available  to  store  selected  paraneters  for  a  particular  test  case.  These 
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data  could  tnen  be  transferred  to  the  POP  n/60  for  results  processing 
after  execution  of  the  current  test  case  was  terminated.  The  other  modi¬ 
fication  would  involve  the  addition  of  software  in  the  foreground  program 
to  generate  an  interrupt  to  the  POP  11/60  upon  occurrence  of  a  predefined 
event.  Also,  in  order  to  facilitate  efficient  data  transfer  between  the 
CAPS-6  and  the  POP  I1/60,‘  specified  variables  in  the  flight  software  would 
be  assigned  to  contiguous  addresses  in  the  CAPS  memory. 

The  system  described  above  would  nave  the  capability  of  controlling 
the  injection  of  the  fault,  recording  the  approximate  time  of  detection, 
and  performing  results  analysis  and  report  generation.  Such  a  system  could 
be  used  to  determine  monitor  coverage. 

4,2.2  Option  Two;  Modest  System  Modifications 

Illustrated  in  Figure  10,  the  second  proposed  system  consists  of  the 
addition  of  special  purpose  hardware  that  would  have  the  capability  of 
passively  monitoring  the  CAPS  transfer  bus  and  recording  the  bus 
transactions  for  analysis  by  the  POP  11/60.  This  EMRU  would  also  contain 
an  internal  clock  for  more  accurate  measurement  of  fault  detection  times 
for  the  FCCs  in  the  RDFCS.  The  BMRO  would  have  the  capability  to  receive 
up  to  16  interrupts  and  decode  them  to  determine  their  origin.  This  option 
would  still  use  the  POP  11/04  for  transferring  data  from  the  CAPS  memory 
locations  to  the  POP  11/60.  The  following  describes  the  functions  and 
capabilities  offered  by  Option  Two. 

POP  11/60  -  The  POP  11/60  functions  would  be  similar  to  those  performed 
under  the  first  option  described.  The  POP  11/60  would  still  be  responsible 
for; 

o  Airplane  simulation 

o  Draper  FI  control 

o  POP  11/04  interface 

o  Results  processing. 

In  addition  to  the  above  functions  the  POP  11/60  would  interface  to 
the  new  unit  described  below. 


DMA  TO  1 1/04 


UNIT  UNDER  TEST 

Figure  10.  FIlS  Option  2  Architecture 

Bus  Monitor/Recorder  Unit  -  The  8MRU  shown  in  Figure  11  would  have  the 
capability  to  passively  monitor  the  CAPS  transfer  bus  and  record  bus 
transactions  in  high  speed  cache  memory.  The  unit  would  also  have  a  DMA 
data  link  to  the  PDP  11/60  for  transferring  the  data  collected  by  the  bus 
recorder.  This  information  would  then  be  processed  by  the  PDP  11/60  into 
tabulated  data  that  represent  the  results  in  the  following  hex  format: 

Address  Data  Read/Write 

The  BMRU  would  also  be  able  to  receive  up  to  16  interrupts  from  the  RDFCS 
pallet.  The  BMRU  would  be  able  to  decode  these  interrupts  to  determine 
where  they  originated.  It  would  use  these  in  conjunction  with  its  clock  to 
measure  fault  detection  times.  An  example  application  might  be  as  follows: 
upon  receiving  a  signal  from  the  PDP  11/60  that  the  fault  is  being  in- 
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Figure  11 .  Bus  Monitor/Racorder  Block  Diagram 
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serted,  the  BMRU  would  read  its  internal  clock.  Upon  receiving  an  inter¬ 
rupt  from  the  pallet  the  BMRU  would  read  the  clock  again,  thereby  giving 
the  fault  detection  time.  By  using  more  than  one  interrupt,  it  would  be 
possible  to  instrument  the  comparator  outputs,  the  flight  software,  and  the 
channel  not  under  test  to  reconstruct  a  fault  detection  sequence.  This 
profile  would  yield  a  time  history  of  when  the  various  monitors  within 
the  FCCs  detected  and  reacted  to  the  injection  of  the  fault. 

Under  Option  Two,  the  PDP  11/04  and  the  CAPS-6  would  nave  the  same 
software  modifications  made  under  Option  One.  With  the  above  outlined 
features  this  system  would  have  the  capability  to  inject  a  fault  and  to 
generate  a  fault  detection  profile.  The  latter  would  be  accomplished  by 
instrumenting  the  various  monitors  and  the  other  channels  with  the  multiple 
interrupt  capability  available.  As  each  interrupt  occurred,  the  BMRU  clock 
would  be  read  so  that  timing  measurements  for  each  monitor  could  be 
determined.  Additionally,  the  CAPS  bus  transactions  would  be  recorded  for 
analysis  by  the  PDP  11/60. 


4.2.3  Option  Three!  Extensive  System  Modifications 

Figure  12  illustrates  the  third  candidate  FIIS  architecture,  which 
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FIgurv  12.  FIIS  Option  3  Architocturo 

provides  enhanced  perfonnance  and  test  results  resolution  over  Option  Two. 
This  architecture  would  have  the  capability  to  continuously  monitor  the 
CAPS  transfer  bus  and  to  store  this  information  for  analysis  by  the  PDP 
11/60  minicomputer.  A  PDP  11/24  minicomputer  would  be  added  for  precisely 
controlling  the  CTAs  and  the  FIU,  without  any  higher  priority  task  such  as 
airplane  simulation.  The  PDP  11/24  minicomputer,  which  is  approximately 
three»and«>a**half  times  faster  than  the  PDP  11/04,  would  encompass  the  same 
capabilities,  and  would  remain  under  the  control  of  the  PDP  11/60. 

As  an  additional  aid,  it  would  be  possible  to  add  a  logic  analyzer  so 
that  other  test  points  could  be  monitored  on  a  selective  basis.  An  example 
of  such  a  test  point  might  be  the  monitoring  of  the  bus  time-out  error 
signal  when  it  is  disabled  for  a  particular  test  case.  The  logic  analyzer 
would  interface  to  the  PDP  11/60  via  a  RS-232  aerial  data  link  for  results 
processing.  The  final  piece  of  hardware  would  be  the  addition  of  a  system 
clock  that  interfaces  to  the  various  system  components  for  improved  time 
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correlation  of  tne  results.  The  follovring  subsections  elaborate  tne  func¬ 
tions  performed  by  major  system  components  under  Option  Three. 


PDP  11/60  -  The  PDF  11/60  under  this  option  would  be  responsible  for  the 
airplane  simulation  and  results  processing.  During  real-time  test  case 
execution,  the  PDP  11/60  would  control  only  the  airplane  simulation.  This 
would  permit  an  expanded  nonlinear  model  to  be  developed  that  would  have 
the  capability  of  supporting  a  pilot's  chair.  The  PDP  11/60  would  probably 
still  do  all  of  the  results  processing.  The  PDP  11/60  would  then  interro¬ 
gate  the  BMRU,  and  access  the  shared  disk  with  tne  PDP  11 /2U  for  test 

results  data  to  process.  The  functions  to  be  accomplished  during  results 
processing  would  remain  to  be  determined  during  detailed  test  case  defini¬ 
tion. 

PDP  n/24  -  The  PDP  11/24  would  interface  to  the  CTAs,  the  shared  disk  with 
tne  PDP  11/60,  the  BMRU,  the  system  clock  and  the  FI.  The  POP  11/24  would 
have  the  same  monitor  capabilities  as  the  existing  PDP  11/04  plus  the 

control  software  for  the  FI.  A  real-time  test  case  scenario  for  the  PDP 
11/24  might  be  the  monitoring  of  the  PDP  11/60  airplane  simulation  via  the 
DMA  data  link  for  a  particular  variable  to  initiate  the  injection  of  a 
predefined  fault.  Just  prior  to  fault  injection  the  BMRU  would,  be  reset 
and  started,  and  then  upon  acknowledgement  that  the  fault  was  detected,  the 
PDP  11/24  would  transfer  the  results  from  the  BMRU  to  the  PDP  11/60  along 
with  any  information  gathered  from  the  CTAs.  Depicted  in  Figure  13,  tne 
software  to  accomplish  these  functions  would  be  very  similar  to  tnat 
described  under  Option  One. 

Bus  Monitor/Recorder  Unit  -  The  proposed  BMRU  would  passively  monitor  all 
transactions  on  the  CAPS  transfer  bus.  The  information  recorded  would 
consist  of  all  data  and  address  lines  and  tne  control  lines.  The  unit 

would  be  able  to  buffer  256K  transactions  in  RAM  before  overwriting  its 
buffer.  The  BMRU  would  increment  a  counter  and  store  the  current  bus 
transaction  as  a  function  of  the  instruction  fetch  signal.  The  unit  would 
be  controlled  from  the  PDP  11/24  by  a  discrete  line  tnat  would  reset  the 
unit's  counter  just  prior  to  fault  insertion.  At  the  termination  of  the 
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Figura  13.  POP-11/24  FI  IS  Software  Stnjctura 
test  case,  the  POP  11/24  would  transfer  the  data  stored  tn  the  unit  to  the 
POP  11/60  for  results  processing. 

Systwi  Clock  -  The  systeo  clock  proposed  would  be  a  simple  oscillator  hav¬ 
ing  outputs  that  are  compatible  with  the  various  devices  in  the  RDFCS 
laboratory.  The  clock  would  be  capable  of  being  read  by  the  various 
devices  in  the  system  or  cleared  to  zero  by  a  discrete  input  from  the  POP 
11/24  (or  possibly  some  other  device).  Under  normal  operation  the  counter 
stages  would  be  updated  at  200  KHz  (5  usee)  rate.  Provisional  circuitry 
would  ensure  that  a  count  could  not  be  lost  while  the  clock  is  being  read. 

Logie  Analyzer  -  The  logic  analyzer  would  be  used  to  selectively  monitor 
various  pins  within  the  FCCs  during  testing.  The  logic  analyzer  would  have 
the  capability  to  buffer  a  small  number  of  events  and  would  be  able  to 
communicate  this  infomation  to  the  POP  11/60  via  a  serial  data  link  for 
results  processing.  The  pins  to  be  monitored  would  be  determined  by  the 
test  case  definition. 

Software  -  As  stated  above,  the  software  for  this  system  would  be  very 
similar  to  that  described  under  the  first  architecture.  The  biggest 
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difference  would  be  where  the  programs  reside.  Table  10  lists  tne  software 
functions' performed  by  the  various  computers  in  the  proposed  system. 

The  extended  capability  offered  by  this  proposed  system  would  allow 
the  CAPS-6  runstream  to  be  analyzed  to  determine  the  effect  of  the  injected 
fault.  This  would  be  accomplished  by  using  the  data  stored  by  the  BMRU  and 
the  supplemental  information  obtained  by  the  logic  analyzer.  By  employing 
a  system  clock,  improvements  in  measuring  fault  detection  times  could  be 
made.  In  addition  by  freeing  the  POP  11/60  of  the  considerable  overhead 
associated  with  the  fault  injection  unit  and  managing  the  CTA  data  link, 
new  functions  could  be  provided. 


TABLE  10  SOFTWARE  MODULES  FOR  OPTIONS  3  AND  4 


COMPUTER 

PROGRAMS 

PDP  11/60 

•  REAL-TIME  AIRPLANE 

SIMULATION 

•  RESULTS  PROCESSING 

•  DMA  CONTROL 

POP  n/24 

•  FI  INITIALIZATION/INSERTION 

•  INTERRUPT  PROCESSING 

•  SYSTEM  CLOCK  CONTROL 

•  CTA  CONTROL 

•  11/04  MONITOR  FUNCTIONS 

•  DMA  CONTROL 

•  BUS  MONITOIV^ECORDER 
INTERFACE 

CAPS-6 

•  BACKGROUND  TEST  EXECUTION 
MONITOR 

•  GENERATE  INTERRUPT  TO 

PDP  11/24 

•  UTILIZATION  OF  EXCESS 

MEMORY 
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4.2»4  Option  Four:  Full-Scale  Syatea  Modiflcationa 


The  fourth  option  as  illustrated  in  Figure  14  is  the  most  advanced  of 
tne  systems  proposed.  This  version  -ncompasses  capabilities  offered  under 
the  previous  options  and  adds  the  capability  of  pin-level  instrumentation 
and  analysis.  With  this  new  feature,  it  is  possible  to  conclusively  deter¬ 
mine  whether  an  injected  fault  results  in  an  undetected  error  or  whether  it 
is  a  "don't  care"  condition. 

The  proposed  additions  consist  of  a  unit  that  would  allow  two  identi¬ 
cal  Chips  to  receive  identical  inputs,  and  would  then  use  one  of  the  cnips 
to  monitor  the  other's  output  for  an  error  condition.  In  this  way  an  error 
introduced  on  the  input  pins  would  be  conclusively  detected  if  it  propo- 
gates  to  the  output  pins.  Another  device  proposed  is  a  logic  state  re¬ 
corder  (LSR)  Which  would  nave  the  capability  to  monitor  the  states  of  up  to 
64  pins  and  buffer  the  information  for  the  PDF  11/60. 

It  is  also  suggested  that  the  four  FCC  CAPS-6  processors  in  the  pallet 
might  be  synchronized  by  using  a  single  system  clock.  This  would  allow 
faster  detection  of  a  propogated  error  so  that  the  data  analysis  tasks 
could  be  simpler.  In  addition,  the  CAPS-6  emulator  delivered  under  NASA 
Contract  NAS2-10270  might  be  modified  for  use  in  results  analysis.  The 
following  subsections  further  describe  the  proposed  modifications  under 
Option  Four. 

Parallel  Chip  Unit  -  This  proposed  unit  would  have  the  capability  of 
allowing  the  chip  under  test  to  be  paralleled  with  an  identical  chip  as 
shown  in  Figure  15.  The  signal  from  the  board  to  one  of  tne  chips  woul..  be 
faulted  momentarily  using  the  250  nanosecond  one-shot  multivibrator,  with 
the  other  chip  receiving  the  Inputs  unfaulted.  (Xitput  comparison  would  be 
used  to  determine  whether  tne  fault  did  or  did  not  propagate  to  the  chip 
output  pins  within  a  reasonable  length  of  time  (e.g.,  5  sec).  Detection  of 
a  state  difference  between  the  two  chips  would  trigger  data  recording  to 
begin.  Used  in  conjunction  with  the  logic  state  recorder  described  sub¬ 
sequently,  the  parallel  chip  unit  would  permit  recording  both  the  normal 
and  the  faulty  chip  output.  In  turn,  this  would  enable  detailed  study  of 
the  propagated  fault  effects. 
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Figure  15.  Parallel  Giip  Unit 

Logic  Stete  Recorder  •  The  proposed  LSR  would  be  a  specialized  version  of 
the  type  are  sold  eonnercially .  It  would  have  the  capability  to  monitor 
and  record  the  states  of  up  to  64  pins.  The  LSR  could  be  triggered  either 
externally  or  by  some  logical  combination  of  the  input  pins.  The  unit 
would  contain  internal  cache  memory  of  sufficient  capacity  to  buffer  the 
data  collected  for  transfer  to  the  PDF  11/60  for  analysis. 

Synchronous  CAPS-.6  Operation  -  It  is  .■'ropoced  that  the  CAPS-6  processors  in 
the  flight  control  computer  might  be  synchronized  by  connecting  them  to  a 
common  clock.  This  capability  would  aid  in  more  conclusive  detection  of 
error  conditions  by  on>line  comparison  of  identical  channels.  Tnis  would 
result  in  improvements  in  measured  fault  detection  times  and  would  help 
bound  the  amount  of  data  collected  after  a  fault  has  been  detected. 

Emulator  Modification  -  The  existing  CAPS-6  emulator  might  be  used  as  an 
aid  in  the  analysis  of  the  results  gathered  during  testing.  With  appro¬ 
priate  modifications,  it  would  be  possible  to  perform  fault  injection  and 
analysis  at  the  microcode  level.  Through  the  combined  use  of  the  emulator 
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and  tne  processor  pin  state  information  collected  during  testing  it  would 
be  possible  to  perform  a  complete  analysis  of  the  test  case  results. 
Methods  would  have  to  be  examined  to  automate  this  process  through  use  of 
either  the  PDP  11/60  or  the  UNIVAC  system  that  hosts  the  CAPS-6  support 
software. 

FCC  Meaory  -  Another  issue  that  should  be  considered  is  the  difference  in 
the  type  of  memory  used  in  the  FCCs  in  the  RDFCS  and  the  units  tnat  are 
flown  on  an  airplane.  The  FCCs  in  the  RDFCS  use  core  memory  for  the  flight 
program,  and  the  production  system  uses  ROM.  Certain  failure  modes  can 
cause  the  CAPS-^  to  overwrite  sections  of  the  core  memory,  thereby  possibly 
invalidating  or  obscuring  the  test  results.  This  problem  could  be  overcome 
in  one  of  two  ways.- 

The  RDFCS  could  be  loaded  with  PROM  mem-ory  that  has  had  the  current 
software  under  test  burned-in.  This  could  be  accomplished  by  using  the 
PROM  programmer  unit  available  at  RDFCS  facility.  The  associated  process 
is  slow,  but  if  the  number  of  test  cases  between  the  reprogramming  of  the 
PROMs  were  large,  this  might  be  a  cost  effective  appproach. 

The  other  possible  solution  might  be  to  add  logic  to  the  Plessey  core 
memory  units  in  the  RDFCS  so  that  the  sections  containing  the  flight  pro¬ 
gram  could  be  writ e- protected .  This  would  involve  considerable  hardware 
modification,  but  would  result  in  greater  productivity  in  applying  test 
cases. 

4.3  SUMMARY  AHD  CRITIQUE  OF  RECOMHEMDATIOHS 


The  four  FITS  architecture  options  are  suimarized  in  Table  11  in  terms 
of  associated  modifications.  This  facilitates  comparison  of  implementation 
requirements.  Table  12  is  a  synopsis  of  capabilities  offerred  by  the 
respective  options,  along  with  a  tentative  approximation  of  relative  costs. 
FIIS  investigation  concerns  and  related  features  are  presented  in  Table  13. 
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TABLE  11  FllS  OPTION  ALLOCATION  MATRIX 


FUNCTIONAL  ALLOCATION 


TABLE  12  COST/BENEFITS  PROJECTIONS 


architecture 

CAPAaitlTIES 

COST* 

OPTION  1 

•  FAULT  TIMING  MEASUREAAENTS  (KOM) 

•  PIN-IEVEL  transient  FAULTS  (  -6  pwc) 

•  FAULT  DETECTION  HISTORY 

1.0 

OPTIOf-l  2 

•  IMPROVED  FAULT  TIMING  MEASUREMENTS 

•  FAULT  DETECTION  TIMING  PROFILE 

•  CAPS  8US  TRANSACTION  ANALYSIS 

1.5 

OPTION  3 

•  IMPROVED  FAULT  TIMING  measurements 

•  EXPANDED  AIRPLAf4E  MODEL 

•  LOCICAl  ANALYZER  FOR  INCREASED 
INSTRUMENTATION 

•  BUS  TRANSACTION  ANALYSIS 

2.1 

OPTION  4 

•  CONCLUSIVE  DETERMINATION  OF 
fault  PJIOPAGATION 

•  STATISTICAL  TESTING 

•  COMPARISON  OF  TEST  RESULTS  TO 

EMULATOR  OUTPUT 

S.O** 

NOTES; 

•  COSTS  ARE  N08MAUZED 
TO  OPTION  I 

♦  •DOES  NOT  INCIUDE  COST 
OF  SYNCHRONIZING  CAPS 
PROCESSORS 
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TABLE  13  SUMMARY  OF  RELEVANT  FI  IS  FEATURES 


CONCERN 

CIRCUITS 

AFFECTED 

relevant  • 

FI  IS  features 

PERMANENT 

ALL 

fault  selection, 

PIN-LEVEL 

FAULTS 

instrumentation 

TRANSIENT 

ALL 

INSTRUMENTATION, 

PIN-LEVEL 

CONTROL  OF  FAULT 

FAULTS 

DURATION 

PATTERN 

MICROPRO- 

250  m«c  ONE-SHOT 

DEPENDENT 

CESSORS, 

FAULTS 

INTERRUPT 

CONTROLLER 

SINGLE  BIT 

CONTROL 

250  mrc  ONE-SHOT 

FAULTS 

STORE 

FAULT 

ALL 

INSTRUMENTATION, 

PROPAGATION 

RDFCS  ENVIRONMENT, 
PARALLEL  CHIP  UNIT 

FAULT 

all 

INSTRUMENTATION, 

DETECTION 

RDFCS  ENVIRONMENT 
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